Obsah Úvod ...................................................................................................................................... 6 Cíle práce ........................................................................................................................... 6 1.
2.
3.
4.
Procesní řízení ............................................................................................................... 8 1.1.
Funkční přístup ....................................................................................................... 8
1.2.
Procesní přístup..................................................................................................... 10
1.2.1.
Proces ............................................................................................................ 10
1.2.2.
Procesní komponenty .................................................................................... 12
Procesní řízení IT sluţeb ............................................................................................. 15 2.1.
ITIL obecně........................................................................................................... 16
2.2.
ITIL v2 .................................................................................................................. 16
2.3.
ITIL v3 .................................................................................................................. 18
ICT Infrastructure Management .................................................................................. 21 3.1.
ICT Infrastructure Management – přehled ........................................................... 21
3.2.
Design and Planning (návrh a plánování infrastruktury) ...................................... 23
3.3.
Deployment (rozmísťování informačních systémů) ............................................. 24
3.4.
Technical Support (technická podpora) ................................................................ 26
3.5.
Operations (správa provozu) ................................................................................. 28
Případová studie – projekt #10 (příprava a nasazení).................................................. 32 4.1.
Příprava projektu ICTIM ...................................................................................... 32
4.1.1.
Poslání ........................................................................................................... 33
4.1.2.
Přínosy ........................................................................................................... 33
4.1.3.
Cíle ................................................................................................................ 34
4.1.4.
Rozsah a předmět .......................................................................................... 34
4.1.5.
Konkretizace přípravných kroků ................................................................... 35
4.1.6.
Fáze projektu a jejich výstupy ....................................................................... 37
4.1.7.
Organizace projektu ....................................................................................... 41
4.1.8.
Rizika ............................................................................................................. 43
4.2.
Návrh a implementace procesu Operations .......................................................... 44
4.2.1.
Fáze 0: Organizační zajištění projektu .......................................................... 44
4.2.2.
Fáze 1: Školení .............................................................................................. 44
4.2.3.
Fáze 2: Návrh standardního systému řízení ................................................... 49 ~4~
5.
4.2.4.
Fáze 3: Změření současného stavu optikou nového systému řízení .............. 56
4.2.5.
Fáze 4: Návrh plánu trvalého zlepšování ...................................................... 58
4.2.6.
Fáze 5: Návrh systému měření výkonnosti.................................................... 59
4.2.7.
Fáze 6: Vytvoření řídící dokumentace nového systému řízení...................... 59
4.2.8.
Fáze 7: Příprava nasazení nového systému řízení do provozu ...................... 60
Případová studie – projekt #10 (pilotní provoz) .......................................................... 61 5.1.
Způsob řízení poţadavků a zaměstnanců .............................................................. 61
5.2.
Návrh úprav procesu Operations pro R2 .............................................................. 63
Závěr .................................................................................................................................... 66 Výsledky .......................................................................................................................... 66 Výhrada první (vlastnictví procesů) ............................................................................ 66 Výhrada druhá (příprava projektu) .............................................................................. 67 Výhrada třetí (více neţ jeden vykazovací systém) ...................................................... 67 Výhrada čtvrtá (organizační struktura versus procesní řízení) .................................... 68 Slovo závěrem ................................................................................................................. 69 Seznam pouţitých zdrojů .................................................................................................... 71 Přílohy ................................................................................................................................. 72
~5~
Úvod Informační technologie (dále IT) jsou jiţ dlouhou dobu kaţdodenní součástí našeho ţivota. Jsou vyuţívány podniky a institucemi všech velikostí od státní správy, přes vědu a výzkum, školství, průmysl aţ po bankovní sektor a pojišťovnictví. V těchto společnostech, zvláště pak středních a velkých1, existují samostatné profese a celá oddělení, která se zabývají výlučně oborem IT - „výrobou“ produktů a poskytováním sluţeb. Patří sem například útvary provozu, správy (administrace), rozvoje, vývoje a testování, bezpečnosti. Nedílnou součástí bývá rovněţ dispečink IT v provozech, kde je nutné sledovat běh kritických systémů a aplikací v reţimu 7x242. Není divu, ţe tyto mnohdy rozsáhlé útvary musejí být řízeny a řízena musí být i dodávka produktů a sluţeb, obecně výstupů, které v nich vznikají. Poslední věta předchozího odstavce nám prozradila směr, kterým se tato diplomová práce (DP) ubírá. Na rozdíl od funkčního řízení, které bylo v minulosti převládající formou organizování, se bude tento text zabývat řízením procesním. Konkrétně, práce nese název „Procesní řízení útvarů IT“. K volbě tohoto tématu mne vedly dva hlavní důvody. Prvním byl zájem o oblast řízení a managament vůbec a druhým pak vzrůstající důraz kladený na procesní řízení ve společnosti, ve které pracuji spolu s mým angaţmá v jednom z projektů, který procesní řízení implementuje. Zmíněné angaţmá se týká vlastnictví procesu Operations a tomuto bude také věnována největší pozornost v praktické části.
Cíle práce Cílem práce je nejprve uvést čtenáře do problematiky procesního řízení. Jakkoliv se můţe tato kapitola zdát tematicky vzdálená, není tomu tak jelikoţ procesní přístup lze aplikovat i na řízení IT útvarů. Následující kapitoly si kladou za cíl zmínit přístupy řízení sluţeb v oblasti informačních technologií se silnou preferencí k procesnímu rámci ITIL v2 (viz slovník v příloze), coţ nám připraví půdu pro praktickou část. Po uvedení teoretických 1
Dělení na základě počtu zaměstnanců, ročních trţeb resp. příjmů, hodnoty aktiv, nezávislosti. Zde se budu zabývat výlučně velkým podnikem, který uvedené ukazatele splňuje 2 Nepřetrţitý provoz (7 dní v týdnu, 24 hodin denně). Mezi další rozšířené patří 5x8, 5x12, 5x16. Reţim provozu bývá součástí smluv o poskytované úrovni sluţeb SLA (viz Příloha #1)
~6~
souvislostí přejdu k aplikaci procesních přístupů v konkrétní firmě a představím projekt, který byl posledních šest měsíců připravován a implementován a v nedávné době vstoupil do fáze pilotního provozu. Jedná se o projekt implementace a nasazení ITIL Infrastructure Managementu (ICTIM) respektive jeho procesů do jednoho z odborů ve velké organizaci. V této části rovněţ popíši návrh procesu Operations dopodrobna (4.2). Kvůli šíři tématu a velkému počtu útvarů v rámci IT popisované organizace bude kladen důraz na oblast provozu IT resp. jednoho konkrétního odboru (Odboru rozvoje infrastruktury – ORI). V části závěrečné dojde k vyhodnocení a návrhům na zlepšení současného stavu v předmětné oblasti. Po závěrečné části následuje část s přílohami, která obsahuje Přílohu #1 „Slovník pouţitých pojmů a zkratek“, Přílohu #2 „Harmonogram projektu č. 10 ICTIM“ a Přílohu #3 „Risk analýza mezi současným a cílovým stavem“. Seznam pouţitých zdrojů je samozřejmostí. Při zpracování textu jsem vycházel z analyzování a následné syntézy materiálů tištěných a elektronických, dále pak z poznatků nabytých studiem na VŠE, BIVŠ a těch získaných samostudiem. Nedílnou součástí byla předchozí i současná praxe ve společnostech komerčního charakteru působících v různých odvětvích ekonomiky.
~7~
1. Procesní řízení Procesní řízení, jak název kapitoly napovídá, se zabývá managementem (řízením) procesů a pohlíţí na činnosti v organizacích jako na procesy. Jeho filosofie, která je zaloţena na ovládání jak řídících tak i výrobních procesů, se značně odlišuje od funkčního (synonymem je v tomto případě „operačního“) přístupu, který vyšel ze zásad klasického managementu. „Přechod od operačního managementu na management procesní je dnes chápán jako zásadní posun paradigmatu“3 [1]. Následující podkapitoly přinesou podrobnější pohled na kaţdý z těchto přístupů, z nichţ ten procesní bude rozebrán podrobněji s ohledem na zaměření této práce.
1.1.
Funkční přístup
Jak jiţ bylo řečeno, tento přístup vychází ze zásad klasického managementu. Zaměřuje se primárně na výsledky respektive důsledky a nikoliv na příčiny. To má svá úskalí v tom, ţe nemusí být odhaleny příčiny neefektivností vedoucí k dosahovaným výsledkům. Je zde prostor pro nízkou produktivitu práce, plýtvání zdroji (v případě IT útvarů se jedná zejména o plýtvání intelektem, dále jde pak o prostoje, zbytečné úkony atd.) a nezřídka se můţeme v podnicích setkat s přezaměstnaností. Následná úsporná opatření potom směřují, často plošně, k jednotlivým funkčním místům a poţaduje se od nich sníţení nákladů (na základě osobních zkušeností okolo 30 %) nebo pracovních míst4. Produktem funkčních přístupů jsou vertikální organizační struktury. Mezi jejich výhody patří jednoznačné určení místa pracovníků v organizaci, přidělení pracovníkům okruh pravomocí souvisejících s jejich odborností a soustředění výkonné moci do rukou vrcholových manaţerů, kteří udělují příkazy svým podřízeným a následně kontrolují jejich plnění. Za další klad bývá povaţována stabilita a přehlednost těchto organizačních uspořádání. Klasickým strukturám je na druhou stranu vytýkáno to, ţe jelikoţ lpí na přesných popisech funkčních míst a na důsledném dodrţování příkazů, nepodporují tvůrčí iniciativy a kreativitu zaměstnanců. Rovněţ, a to mohu opět potvrdit z praxe, vázne spolupráce a 3
Truneček, J. a kol.: Management v informační společnosti. Ediční oddělení VŠE Praha 1997, strana 113 Byl jsem svědkem i takových „praktik“ ţe „pokud ušetřím na nákupu licencí 1000 000Kč, 500 000 Kč zůstane a za dalších 500 000Kč zachovám jednu pracovní pozici – jinak řečeno, nikdo nebude propuštěn” 4
~8~
výměna informací v horizontálních vztazích. Vypadá to potom tak, ţe spolu jednotlivé útvary spíše soupeří, neţli aby hledaly společné řešení problémů. V horším případě se stává to, ţe dochází ke svalování odpovědnosti za nastalé incidenty (pokud si vypůjčím příklad z útvarů provozování infrastruktury vs. provozní podpory aplikací). Shrnuto, dochází ke vzniku komunikačních a kompetenčních bariér, které je třeba odbourat změnou organizování a řízení. Tato změna můţe být v podobě přechodu na horizontální organizační struktury (popřípadě jiné, ale vţdy zohledňující procesní charakteristiky), které vyuţívají méně hierarchické organizační jednotky (se silnými horizontálními vazbami). Čistě teoreticky by šla zachovat i poměrně strmá horizontální organizační struktura, ovšem pak je třeba brát nejvyšší zřetel na to, aby se stal centrem pozornosti proces a jeho průběh napříč organizační strukturou (toto je však nepreferované řešení a v praxi není příliš funkční. Zmínil jsem je pro lepší pochopení tématu organizačních struktur versus procesní myšlení a řízení vůbec). Následující „Obrázek 1“ ukazuje organizační strukturu v diplomové práci popisovaného podniku.
Obrázek 1 „Funkční uspořádání útvarů IT organizace, o které je v textu řeč“ Odbor bezpečnosti IT
Náměstek GŘ pro IT
Odbor controllingu IT
Odbor provozní podpory NŽP
Odbor provozu systémů
Úsek IT Governance
Úsek provozu IT
Odbor rozvoje infrastruktury
Odbor podpory uživatelů IT
Odbor SD
Odbor architektury
Odbor řízení kvality služeb
Zdroj: autor
~9~
Úsek vývoje IT
Odbor vývoje systému X
Odbor řízení projektů
Odbor vývoje systému Y
Odbor péče o interní klienty
1.2.
Procesní přístup
Tento druh přístupu se primárně nezaměřuje na výsledky, jak tomu bylo u přístupu funkčního, ale na příčiny! Předpokládá, ţe příčinou neuspokojivých výsledků jsou špatně nastavené procesy, které je proto nutné narovnat a přenastavit tak, aby bylo eliminováno vše, co nepřináší přidanou hodnotu pro zákazníka. Pokud by se jednalo o radikální a skokové změny, hovořili bychom o reengineeringu (příkladem můţe být konkrétní projekt popisovaný v praktické části). Opakem reengineeringu je potom kontinuální zlepšování procesů, jehoţ průkopníky jsou Japonci (a jejich filosofie Kaizen – důraz na neustálé zlepšování všeho – tento přístup by se dal samozřejmě aplikovat i v IT oblastech). Procesní řízení (neboli BPM z anglického Business Process Management) chápe většinu činností realizovaných v organizacích jako procesy. Existuje velké mnoţství definic, které se liší podle zdrojů, ale já si vyberu dvě5 následující, jelikoţ se hodí pro účel této práce nejlépe a zcela vystihují podstatu zde řešeného problému. „Procesní řízení je filozofie řízení, která hájí integrované pojetí řízení procesu od počátku do konce (anglicky end-to-end, poznámka autora), včetně elementárních činností, v nichţ vzniká produkt nebo sluţba pro daného zákazníka“. „Procesní řízení je plánování a řízení činností nezbytných k dosaţení vysoké úrovně výkonnosti procesů a v identifikování příleţitostí ke zlepšení kvality, provozní výkonnosti a trvalého uspokojování zákazníků. Zahrnuje návrh, řízení a kontrolu a zlepšování klíčových procesů organizace“. Nyní, kdy uţ známe pojem procesní řízení, pojďme si představit co to ten proces vlastně je, jeho hlavní komponenty, druhy a další důleţité souvislosti.
1.2.1. Proces6 [6] Proces by se dal charakterizovat jako propojení dílčích činností (nebo také aktivit či procesních kroků), které transformují vstupy jdoucí do procesu na poţadované výstupy. Nejdůleţitější je, ţe v procesu musí vznikat přidaná hodnota pro zákazníka. Pokud však
5
http://www.itil.cz/index.php?id=914 Mezi procesem a projektem je významný rozdíl. Ten spočívá hlavně v periodicitě. Zatímco proces je opakující se činnost, projekt je typický svou jedinečností. Například nastavení a zavedení procesu/processů předchází projekt 6
~ 10 ~
vstup projde procesem nezměněn (a tudíţ nevznikne ţádná přidaná hodnota) a je předán zákazníkovi coby výstup, můţeme jej charakterizovat jako nástroj procesu. Obrázek 2 „Model procesu“ poskytuje ilustraci procesu obecně. Vysvětlení anglických popisků v obrázku lze najít v následující podkapitole. Obrázek popisuje jednoduchý mechanismus všech procesů, a sice přeměnu vstupů na výstupy (šedá část). Tyto výstupy jsou následně měřeny, vyhodnocovány a dochází k případným korekčním opatřením. Obrázek 2 „Model procesu“
Zdroj: OGC: ICT Infrastructure Management, 2002, Figure B. 2 [3] Klíčové, primární (core processes). Primární procesy jsou ty, které podporují primární business podniku. U výrobních společností to můţe být produkce konkrétních komodit, u bankovních sluţeb proces poskytování půjček a v pojišťovnictví třeba proces poskytování neţivotního pojištění. Podpůrné, sekundární (supporting processes). Sekundární procesy jsou procesy zajišťující především zdroje pro procesy primární a ty, které zajišťují určité vlastnosti jako třeba hlídání jakosti výrobků při výstupní kontrole nebo testování software u firem ~ 11 ~
vyvíjejících programové vybavení. Můţe sem také, podle mého, spadat typicky podpora klíčových business procesů organizace jednotlivými IT útvary. Další dělení procesů by mohlo být na human-centric (nositelem činností jsou především lidé) a system-intensive (u těchto není třeba tvůrčí práce a tudíţ mohou činnosti v těchto procesech vykonávat technologie – člověk zde slouţí spíše jako podpůrný a kontrolní článek nebo se podílí na rozvoji tohoto procesu). Další moţnosti jsou document-centric nebo integration–centric. V návaznosti na toto dělení se kategorizuje i BPMS (systémy, suits). Přechod na procesní řízení můţe mít několik příčin: zvýšení efektivnosti poskytovaných sluţeb a produktů (jsou výstupem z procesů) být v souladu s normami (příprava na certifikaci) zavádění komplexních podnikových systémů (například ERP) přechod na SOA – servisně orientovanou architekturu.
1.2.2. Procesní komponenty Následuje výčet nejdůleţitějších komponent procesu a jejich popis, přičemţ pořadí nerozhoduje, neboť jsou všechny důleţité. Ukázka toho, co by se v přípravné fázi projektu zavádějící proces nebo skupinu procesů mělo stanovovat a definovat, spolu s detailním obsahem procesů, bude popsán v praktické části (kapitola 4. včetně podkapitol). Vlastník procesu (Process Owner) ~ Vlastník procesu je člověk zodpovědný za „svůj“ proces jako celek. Konkrétně za jeho návrh, výkonnost ale i za neustálé zlepšování. K tomu má pravomoc proces řídit v rámci definovaných pravidel prostřednictvím operativních příkazů. Vlastníkem by měl být zvolen člověk, mající největší zájem na výsledku celého procesu. Zpravidla to bývá výše postavený manaţer. Můţe se však stát, ţe je za vlastníka vybrán i například zaměstnanec, který dosud neměl či nemá vedoucí pozici. Zde můţe docházet k situacím, kdy liniový nadřízený „vlastní“ pool lidí, kteří pracují pro jeden čí více procesů. Tito lidé jsou pak sdíleni nejen mezi procesy (a tedy jsou odpovědni více vlastníkům), ale zároveň jsou povinni plnit příkazy přímého liniového nadřízeného. Proto ~ 12 ~
je nutné, aby se organizační struktura co nejvíce blíţila „namalovaným“ procesům. V našem případě (mám na mysli v organizaci, pro níţ pracuji a projekt, který popisuje praktická část), byla situace vyřešena tak, ţe jako vlastníci procesů byli zvoleni linioví manaţeři. Další skupinu vlastníků tvořili zaměstnanci, patřící pod tyto liniové manaţery. Jelikoţ tedy všichni tito lidé spolupracovali od začátku na společné věci a věděli, oč jde, nebyl problém s řízením těch samých zaměstnanců více vlastníky (manaţery) a vţdy jsme se dohodli. Ne vše je vţdy ideální a tak bude o této věci ještě krátce pojednáno v závěrečné části. Cíle procesu (Process Goals): cíle a záměry existence procesu. Popis procesu: stručná charakteristika procesu, která je potom detailně rozepsána v procesních modelech. Role (Roles): Role procesu jsou vykonavatelé procesu – procesních kroků. V praxi to funguje tak, ţe jsou ve fázi návrhu procesu nadefinovány konkrétní procesní role a do těch jsou poté jmenováni jednotliví zaměstnanci. Platí, ţe jednu roli můţe zastávat libovolný počet osob a také, ţe člověk můţe vystupovat v libovolném počtu rolí (i v rámci jiných procesů). Spolu s takto vytvořenými rolemi jsou stanoveny jejich oblast odpovědnosti, způsob rozvoje jejich členů a rovněţ KPI pro hodnocení výkonu. O tom se můţeme přesvědčit podrobně v kapitole 4.2.3. Aktivity (Activities): aktivitami rozumíme jednotlivé procesní kroky tak, jak jdou za sebou v procesu. Mohou být stanoveny podmínky, při kterých je moţné přejít k navazujícímu kroku. Dále musíme stanovit osoby či procesy, na které eskalovat v případech, kdy nemohou být dané podmínky z nějakého důvodu splněny. Vstupy procesu (Process Input): Za vstupy procesu můţeme označit vše, co vstupuje do procesu a je následně přeměněno procesními aktivitami na výstupy. U procesů popisovaných dále v diplomové práci jsou to nejčastěji dokumenty či data. Výstupy procesu (Process Output): Jako výstupy označujeme dokumenty, data a vše, k čemu jsme se zavázali, ţe budeme dodávat. V pilotním provozu jsme přišli na to, ţe je dobré měřit rovněţ kvalitu dodávaných výstupů, coţ nebylo ve fázi návrhu procesu uvaţováno. ~ 13 ~
Výkony procesu: produkt nebo sluţba, kterou proces poskytuje svému zákazníkovi (hlavní výstup). V procesu Operations, který je popsán v praktické části je to „Stabilní a bezpečná ICT infrastruktura“. Metriky: Metrikami nazýváme veličiny, pomocí kterých je hodnocena výkonnost a hospodárnost procesu. Jejich stanovení je nezbytně důleţité pro management a pro vlastníky neboť jim říká, kde a co v procesu nastavit, upravit popř. eliminovat, aby splňoval stanovená očekávání. Pokud chceme, aby se náš proces neustále zlepšoval, je třeba tyto metriky nejen definovat, ale také monitorovat a následně vyhodnocovat. Výsledky tohoto vyhodnocení potom slouţí vlastníkům procesů jako podklady pro zlepšování neuspokojivých parametrů jimi vlastněných procesů. V procesním řízení jednoduše platí rčení: „pokud neměřím, neřídím“. Dokumentace: dokumentaci procesu tvoří seznam všech modelů, dokumentů a pravidel stanovených vlastníkem procesu. V rámci návrhu procesu Operations pro první release mnou navrţená dokumentace obsahovala podrobný popis procesu, workflow, role, kulturu a řadu dalších materiálů, které je moţné nalézt v kapitole 4.2. Vše završil dokument s názvem „Řídící dokumentace procesu“, který formalizoval nově navrţený proces řízení (není součástí diplomové práce)7. Systémy: jsou aplikace umoţňující nebo podporující provádění procesu. V kapitole 4.2.3 je označuji jako „nástroje pro podporu řízení procesu“ (workflow nástroje, kancelářské nástroje), popřípadě konkrétní nástroje vyuţívané při tvorbě výstupů. Legislativa: legislativou se rozumí obecně závazné právní předpisy a vnitropodnikové předpisy, které určují rámec a prostředí procesu (podmínky dané z okolí). Tyto informace nesl, v našem případě, dokument s názvem „Řídící dokumentace procesu“. V případech zavádění nových či při změnách stávajících procesů je ještě dobré uvaţovat dopady a potřeby pro implementace / změny procesů.
7
Nezahrnul jsem jej do DP, protoţe pouze shrnuje materiály uvedené v kapitole 4.2 do logického celku pro účely řízení odboru v organizaci
~ 14 ~
2. Procesní řízení IT služeb Následující obrázek „Vztah IT sluţeb k…“ ukazuje vztah IT sluţeb k podnikové strategii a firemním procesům8. Podniková strategie je smyslem existence kaţdého podniku a je v ní ukotven směr, kterým se bude společnost ubírat a jaké jsou její cíle pro další období. Firemní procesy potom pomáhají tuto firemní strategii naplňovat a jejich pomocí organizace dosahuje stanovených cílů. Ke svému výkonu potřebují tyto procesy informační a komunikační technologie (ICT technologie). Pomocí ICT technologie jsou poskytovány sluţby, které je třeba řídit a tyto sluţby neustále zlepšovat. Dříve byly IT sluţby poskytovány „tak nějak“ automaticky a jejich řízení (spolu s důrazem na kvalitu a hospodárnost) nebylo zdaleka samozřejmostí. Tato doba, zdá se, je jiţ minulostí a v současné době se poskytováním a řízením IT sluţeb zabývá celá řada metodik, norem a „best practice“9. Popis těch nejrozšířenějších a jejich vztah bude následovat v podkapitolách níţe. Obrázek 3 „Vztah IT sluţeb k podnikové strategii a firemním procesům“
Zdroj: http://www.itil.cz/index.php?id=982 [5] 8
Jsou tam naznačeny i ICT technologie, coţ je pro nás, z hlediska zaměření této práce, velice výhodné Asi nejznámějším zástupcem tzv. „best practice“ je ITIL (viz slovník v příloze). Tato „best practice“ nám nic nepřikazují, ale pouze doporučují a ukazují směr, jakým by se měly IT sluţby ubírat a jak je implementovat. „Best practice“ je tedy souborem nejlepších zkušeností z konkrétního oboru a mají doporučující charakter 9
~ 15 ~
2.1.
ITIL obecně
ITIL je zkratkou pro „Information Technology Infrastructure Library“ a v překladu to znamená „knihovna infrastruktury informačních technologií“. [8] Představuje návody a nejlepší zkušenosti z praxe o tom, jak řídit IT sluţby zákazníkům, provoz a rozvoj infrastruktury nebo třeba jak na vztahy s dodavateli. Bývá téţ označován jako procesní rámec pro oblast IT Service Managementu. ITIL je šířen jako sada kniţních publikací, kde kaţdá z nich popisuje určitou oblast řízení sluţeb a ICT infrastruktury. Počet a obsah publikací se liší v závislosti na verzi. Zatímco ITIL v2 popisuje knih osm (devátá nebyla původně součástí a je určena spíše pro menší IT jednotky), ITIL v3 sestává z pěti knih10. Mezi oběma verzemi existují poměrně velké rozdíly, které budou patrné po přečtení charakteristik kaţdé z nich. Faktem ale zůstává, ţe se obě verze spíše doplňují. Jiţ zde zdůrazním, ţe projekt popisovaný v kapitole 4. byl zaloţen na ITILu v2, konkrétně ICT Infrastructure Managementu a jeho procesech. Tento přístup byl zvolen vedením projektu a po dotazu na školitele externí společnosti (Win4all, s.r.o.) po důvodu této volby jsem obdrţel odpověď ve smyslu, ţe ITIL v2 je vhodnější pro praktické vyuţití kdeţto ITIL v3 pro vzdělávací účely (nejedná se o citaci).
2.2.
ITIL v2
Obrázek 4„Jádro ITIL v2“
Zdroj: OGC: ICT Infrastructure Management, 2002, Figure 1.4 [3]
10
Květen, 2007. Můţeme tedy vidět, ţe ani zatím poslední verze ITILu není z nejnovějších
~ 16 ~
Schéma na předchozím Obrázku 4 „Jádro ITIL v2“, ukazuje přehled ITILu v2 dle jeho základních publikací, které tvoří jeho jádro. Osmá publikace (Software Asset Management – Pojednává o správě SW aktiv) a devátá (Small - Scale Implementation) jsou doplňkové a nejsou zde zobrazeny. Základní knihy jsou tyto: Service Support (Podpora sluţeb) Service Delivery (Dodávka sluţeb) Knihy Service Support a Service Delivery tvoří dohromady IT Service Management. Tedy nikoliv knihy samotné, ale procesy v nich popsané. Jsou srdcem ITILu v2 a v podnicích, při školeních i certifikacích11 se na ně soustřeďuje největší pozornost. Byly i předmětem programu SIP 1-912. ICT Infrastructure Management (Správa infrastruktury ICT) Zabývá se řízením infrastruktury. Ačkoliv je implementace těchto procesů nezbytná pro stabilní fungování ICT infrastruktury, je tato skupina procesů neprávem opomíjena a nemůţe být ani předmětem certifikace ISO 20000. V naší organizaci naštěstí jeden člen vedení pochopil nezbytnost této rodiny procesů, a proto vznikl projekt č. 10 programu SIP. Planning to Implement Service Management (Plánování implementace správy sluţeb) „Modul se zabývá implementací nebo zlepšením ITIL v organizaci a uvaţuje takové aspekty, jako kde a kdy začít, organizační změnu, změnu kultury, plánování projektu a programu, definici procesu a zlepšování výkonnosti“.13 [2] Application Management (Správa aplikací) Zabývá se správou aplikací, mimo jiné jejich návrhem, výstavbou, implementací a provozem. Business Perspective (Perspektiva businessu) 11
Jak certifikací Foundation (ve verzi 2 – nyní moţno pouze na verzi 3), tak lze tyto procesy certifikovat ISO 20000 12 Vysvětleno ve čtvrté kapitole 13 Úvodní přehled ITIL, itSMF
~ 17 ~
Tato kniha se zaměřuje a poukazuje na důleţitost řízení IT sluţeb z hlediska jejich nezbytnosti pro business a dále akcentuje důleţitost efektivních vztahů s businessem, jasných rozhraní a včasných dodávek tak, aby byl maximalizován jeho prospěch. Security Management (Správa bezpečnosti) Zabývá se definovanou úrovní bezpečnosti informací, IT sluţeb i celé infrastruktury. V případě zájmu o toto téma existují na internetu bohaté zdroje. Jako úvodní přehled doporučuji skutečně přehlednou „broţurku“ Úvodní přehled ITIL, itSMF, kde lze nalézt i jednotlivé procesy náleţející do výše uvedených skupin (knih).
2.3.
ITIL v3
ITIL v3 se od svého předchůdce odlišuje hned v několika aspektech. Má kompletně jinou strukturu (viz Obrázek 5) a i jeho silnější orientace na ţivotní cyklus sluţeb je markantní změnou. Obrázek 5 „ITIL v3“
Zdroj: http://www.iet-solutions.com/desktopdefault.aspx/tabid-4/9_read-4/ [9]
~ 18 ~
V rámci ITIL v3 existují publikace v následující struktuře: Service Strategy (Strategie sluţeb) Strategie sluţeb je něco, co nemůţe stát samo o sobě. „Strategie sluţeb je opravdovým jádrem ţivotního cyklu ITIL V3. Zaměřuje se na návody všem poskytovatelům sluţeb IT a jejich zákazníkům, jak provozovat a dlouhodobě udrţet jasnou strategii sluţeb“. [12] Service Design (Návrh sluţeb) „Návrh adekvátních a inovativních sluţeb IT včetně jejich architektury, procesů, politik a dokumentace tak, aby bylo dosaţeno současných i budoucích poţadavků businessu“. Service Transition (Přechod sluţeb) „Rolí přechodu sluţeb je dodat sluţby poţadované businessem do provozního vyuţití“. Service Operation (Provoz sluţeb) „Účelem provozu sluţeb je dodávka dohodnutých úrovní sluţeb uţivatelům a zákazníkům, a správa aplikací, technologií a infrastruktury, které podporují dodávku těchto sluţeb“. Continual Service Improvement (Neustále zlepšování sluţeb) „Neustálé zlepšování sluţby (CSI) se zabývá udrţením hodnoty pro zákazníky prostřednictvím neustálého vyhodnocování a zlepšování kvality sluţeb a celkové vyspělosti ţivotního cyklu ITSM a podpůrných procesů“. K ITIL ještě existuje řada alternativ jako například (COBIT, eTOM), normy kvality ISO20000 (lze pomocí ní certifikovat procesy IT Service Managementu ITILu). Zde však byla a bude věnována pozornost ITILu v2, protoţe na ní je postavený celý projekt, který představí kapitoly 4. 5. a podkapitola s výsledky. Na závěr tohoto tématu si vypůjčím větu a uvedu jako citaci14: [5] „Přestoţe řízení samotné technické a technologické podstaty infrastruktury informačních a komunikačních technologií je nutnou podmínkou správného fungování IT sluţeb, není podmínkou dostačující - je totiţ ještě nutné nějakým způsobem řídit i samotné IT sluţby, kvůli kterým tato infrastruktura existuje => toto řízení je nazýváno IT Service Managementem (ITSM)“.
14
http://www.itil.cz/index.php?id=982
~ 19 ~
Jelikoţ v podniku ve kterém pracuji, nastal přesně opačný případ a změny (přechod na procesní řízení podle ITILu v2) se týkaly pouze řízení dodávky IT sluţeb, větu z předchozího odstavce invertuji a tvrdím, ţe pro úspěšné a kvalitní dodávky sluţeb není soustředěnost pouze na IT Service Management správná a není to tedy podmínka dostačující. Proto se budu v následujících kapitolách zabývat řízením technické a technologické podstaty informačních a komunikačních technologií.
~ 20 ~
3. ICT Infrastructure Management Tato kapitola si klade za cíl ukázat rodinu procesů zabývající se řízením ICT infrastruktury v té míře podrobnosti, aby byla lépe pochopena část praktická a procesy navrhované v jejím rámci jiţ byly důvěrně známé. Bude následovat postupné představení Infrastructure Managementu jako celku a poté jednotlivých procesů (jejich mise, cíle, vstupy, výstupy a role). Vţdy půjde o nejdůleţitější charakteristiky jednotlivých procesů a nikoliv o vyčerpávající výpis. Pro tento odkazuji čtenáře na literaturu, která se tímto důkladně zabývá, konkrétně na knihu ICT Infrastructure Management v rámci ITIL v2 (uvedeno v seznamu literatury). Proces Operations bude posléze popsán ve vyšší míře detailu a tím lépe přiblíţí problematiku a osvětlí důvody některých kroků ve 4. kapitole (4.2). Popis procesů v této kapitole bude vycházet z ITIL v2. Zmiňuji to proto, ţe si kaţdý ve fázi návrhu procesů smí určovat své vlastní mise, cíle, vstupy a výstupy, role a další. V případě zájmu pak bude zajímavé porovnat nabídku ITIL v2 (3.5) a návrh procesu na konkrétním příkladě (4.2).
3.1.
ICT Infrastructure Management – přehled
ICT Infrastructure management se zabývá procesy, organizací a nástroji pro podporu stabilní a bezpečné ICT infrastruktury a je tedy základem pro procesy v rámci IT Service Managementu (dále jen ITSM). Je aţ zaráţející, ţe je často v organizacích skupina těchto čtyř procesů opomíjena (tato zmínka je i v oficiální knize ICT Infrastructure Managementu) a jsou implementovány pouze ty z rodiny ITSM. Nejinak tomu bylo i ve společnosti v níţ pracuji, a proto byl navrţen a implementován projekt, který bude podrobně popsán ve čtvrté kapitole. POZOR! Procesy ICT Infrastructure Managementu není moţné certifikovat normou kvality ISO 20000. Přínosy řízení ICT Efektivní a dobře řízená ICT infrastruktura má řadu výhod jak pro business tak pro IT samotné. Mnoho z těchto přínosů je měřitelných a mají hmatatelnou přidanou hodnotu, takţe lze dobře ospravedlnit jejich implementaci. Mezi hlavní přínosy patří tyto: zvýšení dostupnosti sluţeb a jejich kvality. ~ 21 ~
Toto je velmi dobře měřitelný efekt, kde mohou jako sledované veličiny vystupovat například dostupnost sluţby (měřena v procentech) nebo spolehlivost (měřena počtem výpadků za časové období). Tyto veličiny a cílové hodnoty bývají předmětem uzavíraných SLA respektive OLA. minimalizace rizika vzniku poruchy na části infrastruktury a v případě ţe k němu dojde, jde o minimalizace jejího dopadu na zákazníka. Dobře navrţená a řízená infrastruktura by měla předcházet incidentům a napomáhat jejich rychlému odstranění. Zde je moţná úzká spolupráce s procesem Availability Managementu (AvM) a Service Continuity Managementu (SconM). niţší náklady na poskytování IT sluţeb. Přiřazení nákladů ke konkrétním výstupům, zjištění struktury nákladů (na zaměstnance, HW, SW, externisty) a následná moţná eliminace v oblastech, kde by se dalo ušetřit. zvýšená produktivita klíčových pracovníků ICT a jejich optimalizace vyuţití pro jednotlivé procesy. Identifikace těch zaměstnanců, kteří spíše provozují a těch určených pro proces Deployment (Dep), případně Technical Support (TS). Bude-li například vyhrazena skupina lidí pouze procesu Operations (OPs), tito zajistí bezporuchový běh infrastruktury a jiní se budou moci zabývat instalacemi apod. Nebudou tedy dělat všichni všechno. předcházení problémům. Předcházení potenciálním potíţím s kapacitními a výkonovými nedostatky, nedostupností sluţeb a provádění preventivních a korekčních opatření. lepší plánování vyuţití současných zdrojů infrastruktury a moţnost tvorby dlouhodobých strategických plánů jejího dalšího rozvoje. identifikace nových technologií, které mohou pomoci sniţovat pořizovací i provozní náklady, zvyšovat úroveň poskytovaných sluţeb a celkově tak zvýšit podporu klíčových zákazníků.
~ 22 ~
3.2.
Design and Planning (návrh a plánování
infrastruktury) Definice procesu ~ Proces Design & Planning se zabývá vytvářením, údrţbou a prosazováním ICT strategie, standardů, politik a plánů v oblasti ICT infrastruktury v souladu s potřebami obchodního plánu organizace. Jde především o dlouhodobá a strategická rozhodnutí jakým směrem se má společnost ubírat co se ICT týče. Proto je třeba věnovat tomuto procesu nemalou pozornost neboť zásadně ovlivňuje budoucí úroveň podpory zákazníků. Cíle ~ Vytvářením ICT strategií, politik, plánů a architektury umoţnit podporu obchodních plánů společnosti ICT prostředky ve správný čas a za efektivní náklady schopnost prosazovat strategie a plány do krátkodobých plánů a řešení trvalé zvyšování kvality ICT sluţeb v souladu s rozvojem trhu a obchodními potřebami společnosti dlouhodobě sniţovat a optimalizovat náklady na ICT infrastrukturu Vstupy vize, strategie, cíle, politiky a plány celé organizace a businessu Současné, existující strategie IS a ICT infrastruktury vč. celkové IS/ICT architektury. Dále potom plány finanční, kapacitní, plány dostupností, bezpečnostní politiky, katalog sluţeb a v neposlední řadě uzavřená SLA, OLA, UC ve spolupráci se Service Level Managementem (SLM). současné prostředí ICT. Pouţívané technologie, procesy a procedury, znalosti a zkušenosti zaměstnanců, aplikační strategie a architektura a další Výstupy ICT strategie, politiky, plány a standardy a celková ICT architektura procesy a procedury procesu Design and Planning ~ 23 ~
reporty ze SWOT analýzy business cases a studie proveditelnosti, projektové plány plány, schémata a topologie prostředí aj. Role ICT Planner / Strategist15 Pracovník v této roli je zodpovědný za vytváření strategií a plánů a koordinuje implementaci změn ICT infrastruktury podle platných plánů. ICT Designer / Architect Zabývá se celkovou koordinací a návrhem ICT infrastruktury. Mezi jeho hlavní zodpovědnosti patří navrhovat bezpečnou a pruţnou infrastrukturu, která bude splňovat všechny nynější a očekávané budoucí poţadavky organizace. K tomu všemu udrţuje potřebnou dokumentaci v aktuálním stavu. Poznámka: vlastník je rovněž jednou z procesních rolí. Ovšem protože je součástí všech procesů a jeho charakteristika by se neustále opakovala, nebudu jej zmiňovat u jednotlivých procesů a pro popis náplně jeho práce a zodpovědností odkazuji čtenáře na kapitolu 1.2.2.
3.3.
Deployment (rozmísťování informačních systémů)
Definice procesu ~ Deployment proces se zabývá implementací a nasazením ICT řešení podle zadání a plánu s minimálním dopadem na provoz business procesů. Jinými slovy jde o tvorbu nových a modifikace stávajících technických řešení při dodrţení standardů definovaných v organizaci prostřednictvím procesu Design and Planning. Je tedy důleţité, aby bylo nové řešení plně integrovatelné do stávající infrastruktury s minimálním dopadem na stávající provoz a tím na sluţby poskytované zákazníkům.
15
Zde jsem si nekladl ambice překládat názvy rolí na české ekvivalenty. Není to pro potřeby pochopení pracovní náplně rolí důleţité. Stejně tomu bude i u následujících procesů
~ 24 ~
Cíle vytvoření a údrţba takového plánu nasazení, který zajistí všechny potřebné zdroje pro plánovanou dodávku zajištění nezbytné dokumentace pro procesy Operations a Technical Support zajištění nezbytných informací pro ty, kteří budou konkrétní nasazení provozovat tedy určitá forma zaškolení zajistit, ţe nasazení budou v souladu s organizačními standardy a budou odpovídat stanoveným plánům a poţadavkům v zadání Vstupy specifikace zadání, dokumentace, standardy, procedury, architektura z D&P popis provozních procesů z Operations popis plánovaných změn z Change Managementu příprava cílového prostředí pro nasazení Výstupy informace a zaškolení pro novou infrastrukturu dokumentace, postupy a návody pro nová ICT řešení aktualizace CMDB (viz slovník v Příloze #1) aj. Role Deployment Project Manager Zaměstnanec je v této roli odpovědný za přípravu plánu nasazení a alokaci zdrojů pro dodávku řešení. Deployment Coordinator Deployment Coordinator je odpovědný za koordinaci činností mezi procesem Deployment a okolními procesy, zajištění přípravy prostředí k nasazení dodávky, zajištění parametrů pro předání dodávky a zajištění vlastního předání. ~ 25 ~
Deployment Analyst Pracovníci pro tuto roli jsou odpovědní za analýzu stávajícího stavu, realizovatelnost plánovaného nasazení a dodrţení parametrů nezbytných pro předání. Deployment Team Member Odpovědnost role Deployment team member je v rámci vlastního nasazení dodávky podle zadání nastavených parametrů.
3.4.
Technical Support (technická podpora)
Definice procesu ~ Technical Support rozvíjí znalosti pro hodnocení, podporu a zastřešování
všech
stávajících
a
budoucích
ICT
řešení
implementovaných
a
provozovaných v organizaci. Pro tento proces by měli pracovat zaměstnanci s největší technickou odborností za danou část infrastruktury a typicky tak poskytovat například podporu třetí úrovně. Dále se TS angaţuje ve vývoji a výzkumu nových technologií a má úzkou vazbu s ostatními procesy Infrastrukturního Managementu. V rámci Technical Support rozeznáváme tři hlavní podprocesy, jimiţ jsou = Research and Evaluation (testování a ověřování návrhů nových či změn stávajících řešení před nasazením Deploymentem, analýza a interpretace výstupů z rozmanitých ICT nástrojů, detailní reporting výkonnosti infrastruktury) = Projects (vytváření a údrţba testovacích a provozních prostředí včetně dokumentace, odborná podpora projektovým týmům a Release Managementu při testování a uvádění nových releasů infrastrukturních řešení do provozu) = Business as Usual (aktivity jako tvorba, udrţování a rozšiřování báze znalostí, dále pak hledání a identifikace příleţitostí k neustálému zlepšování a ostatní aktivity probíhající na denní bázi a nepatřící do ţádného z okolních procesů) Cíle tvorba analýz a doporučení pro nové i stávající technologie
~ 26 ~
návrhy „disaster recovery“ řešení poskytování technické podpory pro dodavatele a udrţování vztahů s nimi rozvoj technické dokumentace, údrţba báze znalostí Vstupy dokumentace současné ICT infrastruktury, například její mapa a/nebo popis CI uzavřené kontrakty s třetími stranami (UC), OLA, SLA a další případná ujednání výstupy Release Managementu, taktiky procesu Deployment data z monitorovacích nástrojů dovolující vytváření rozmanitých pohledů na infrastrukturu včetně její utilizace nebo tvorbu trendů provozní poţadavky vyvolávající vlastní potřebu znalostního potenciálu Technical Support procesu Výstupy analýzy a doporučení pro jednotlivá CI a pro infrastrukturu jako celek podpora Incident Managementu a Problem Managementu při řešení incidentů respektive problémů asistence procesu Deployment při realizacích změn infrastruktury analýzy a doporučení jako podklad pro tvorbu ICT plánů a strategií výsledky testů prováděných v testovacích laboratořích a pomocí rozmanitých nástrojů aj. Role Technical Support Manager Technical Support Manager je odpovědný (mimo typických zodpovědností vlastníka procesu pokud to není tatáţ osoba) za proces TS ve společnosti. Odpovídá tak za koordinaci činností a aktivit dalších rolí v rámci procesu TS, schvaluje a nastavuje
~ 27 ~
propojení s dalšími procesy. Odpovídá i za pravidelnou tvorbu reportů a aktualizaci báze znalostí. V souladu s potřebou CI udrţuje bázi znalostí na poţadované úrovni. Technical Planner Spolupracuje při výzkumu a vývoji nových ICT infrastrukturních řešení a podílí se na technickém plánování a konfiguraci nasazovaných částí infrastruktury. Technical Support Analyst Hlavní odpovědností v roli TS Analyst jsou analýzy ICT infrastrukturních problémů, spolupráce s D&P na tvorbě nových provozních poţadavků, implementace taktických zlepšení sluţby, asistence při tvorbě studií proveditelnosti, rozvoj, údrţba dokumentace a procedur, asistence na pilotech ICT komponent, tvorba a vysvětlování metrik a reportů managementu. Technical Support Specialist / Team Member Hlavní odpovědností zaměstnanců v této roli jsou analýzy ICT infrastrukturních problémů, diagnózy technických problémů, které nelze vyřešit jinde, dodání odborné rady a vedení pro všechny ostatní oblasti, podpora, rozvoj, konfigurace a integrace všech management nástrojů a procesů. Spolupracuje s Deploymentem při nasazení nových technologií.
3.5.
Operations (správa provozu)
Definice procesu ~ Proces Operations zahrnuje všechny aktivity a měření, nezbytné k poskytování ICT sluţeb prostředky ICT infrastruktury. To vše za účelem splnění dohodnutých smluv (SLA) a dosaţení cílů businessu. Ačkoliv je tento proces nedílnou součástí a podporuje ostatní procesy v rámci ICT Infrastructure Managementu a IT Service Managementu, je spíše konzervativní a inklinuje k udrţování jistého status quo. Zaměřuje se především na prevenci a monitoring. Obrázek „Monitor-control loop16“ ukazuje jednoduché schéma fungování tohoto procesu. Input (vstupy do procesu). Typicky to můţe být seznam uzavřených OLA, SLA, UC; Dokumentace, návody a postupy; různé analýzy a doporučení. 16
Jedná se o klasickou zpětnovazební smyčku známou například z kybernetiky. Ukazuje, jak můţe výstup nějakého systému zpětně ovlivňovat jeho vstup
~ 28 ~
Function. Udrţování status quo. To můţe být například udrţení serveru v provozuschopném stavu s určitou definovanou dostupností. Output (výstupy procesu). Hlavním výstupem procesu Operations je „Stabilní a bezpečná ICT infrastruktura“. Monitor. Sledování funkce a výstupů procesu a následné porovnávání „Compare“ se stanoveným „Norm“. Compare. Srovnávání. Norm. Norma, kterou vlastník procesu stanoví v rámci návrhu procesu a hodnoty, které jsou uzavřeny ve smlouvách. Control. V případě nesrovnalostí, kdy se v „Compare“ ukáţe, ţe se data získaná z fáze „Monitor“ dostávají mimo pásmo stanovené v „Norm“, dochází k nápravným opatřením „Control“. Při poskytování sluţeb je nutné si uvědomit, ţe je důleţité doručit zákazníkovi sluţbu v kvalitě, která je součástí uzavřených SLA17. Zákazníkovi (uţivateli) bude zcela určitě jedno, jestli máme server, který mu poskytuje sluţby dostupný na sto procent, kdyţ tuto dostupnost zhatí pomalá odezva tohoto serveru. Obrázek 6 „Monitor-control loop“
Zdroj: ICT Infrastructure Management, ITIL v2, Figure 4.1 [3] 17
Všechny provozní cíle by měli být odsouhlaseny a zdokumentovány v SLA respektive OLA. Tyto stanovené cíle musí být měřitelné, aby se dali hodnotit a reportovat jejich dodrţování
~ 29 ~
Cíle u provozované infrastruktury zajistit, aby byla spolehlivá, pruţná, robustní, bezpečná a umoţňovala kvalitní a efektivní podporu business procesů organizace provozovat, řídit a udrţovat ICT infrastrukturu, která umoţňuje doručování ICT sluţeb zákazníkům, které jsou nasmlouvány v SLA Vstupy současná ICT infrastruktura provozní procesy a procedury strategie, politiky, plány, standardy a architektura UC by měly být konzistentní a podporovat uzavřená SLA vyjednaná OLA, která musí být konzistentní a musí podporovat uzavřená SLA Výstupy stabilní a bezpečná ICT infrastruktura knihovna provozní dokumentace obsahující informace o provozních postupech informace o všech událostech nastalých na ICT infrastruktuře provozní skripty, plány a procedury plány dávkových úloh, kalendáře záloh a plánovaných tiskových úloh provozní nástroje poskytující informace o stavu provozované infrastruktury a jejich sluţeb Role Production Services Manager / Operations Management / Shift Leader Člověk v této roli je zodpovědný za koordinaci a řízení týmu provozního personálu. Měl by motivovat a rozvíjet znalosti svých „podřízených“. Dále je zodpovědný za to, ţe jsou provozní procedury nastaveny správně a správně podporují doručování ICT sluţeb zákazníkům. Rozvíjí a zlepšuje provozní procesy v rámci procesu Operations. ~ 30 ~
Operations Analyst Tato role se stará o plnění nasmlouvaných cílů, poskytuje podporu Service Desku a Incident Managementu. Dále pak spolupracuje s dodavateli, udrţuje provozní dokumentaci a je zodpovědná za stabilitu a monitoring svěřených systémů. Poznámka: V návrhu procesu (kapitola 4.2) jsem tuto roli přejmenoval na roli Administrátor. Storage and Backup Management Role zodpovědná za zálohovací řešení v organizaci. Jelikoţ jsou její činnosti (aţ na jistá specifika spojená se zálohováním) podobné roli Operations Analyst (Administrátor), spojil jsem je v jednu roli. Scheduling Analyst Je zodpovědný za plánování a dodrţování naplánovaných akcí a úloh tak, aby nebyla porušena OLA respektive SLA. Database Administrator Role zodpovědná za databázová řešení v organizaci. Jelikoţ jsou její činnosti (aţ na jistá specifika spojená s provozem databází) podobné roli Operations Analyst (Administrátor), spojil jsem je v jednu roli.
~ 31 ~
4. Případová studie – projekt #10 (příprava a nasazení) Následující dvě kapitoly popisují přípravu a průběh projektu v jedné nejmenované firmě s počtem zaměstnanců přesahujícím pět tisíc. IT oddělení má potom okolo čtyř set pracovníků. Konkrétní čísla nejsou důleţitá, uvedené údaje jsou pro představu a pro náš záměr plně dostačují, nehledě na to, ţe se neustále mění. Celý projekt č. 10 nese pojmenování „Projekt implementace procesů řízení a provozu infrastruktury IT“, ale jako pracovní název budeme pro jednoduchost vyuţívat zkrácené „ICTIM“. Je dodatečnou součástí tzv. SIP (Stability Improvement Program) programu, který implementaci procesů infrastructure managementu předcházel. SIP původně zahrnoval devět projektů, které měly za úkol uvést v ţivot18 především procesy v rámci Service Support a Service Delivery oblastí (ITSM). Na základě faktu, ţe oblast Service Managementu potřebuje ke svému fungování standardně řízenou a provozovanou infrastrukturu poskytující „výrobní linku” pro servis sluţeb, projekt ICTIM měl za úkol provést návrh a implementaci procesů, které by zajistily ono správné řízení a provoz infrastruktury. Řídí se především podle ITILv2 za občasného vyuţití standardu řízení kvality ISO 20000, technik Six Sigma, Lean nebo 8 kroků změny od J. P. Kottera. Celý průběh byl veden externím konzultantem, který jiţ dobře prostředí společnosti znal z předchozích účastí na jiných projektech. Moje účast na projektu byla aktivní z titulu vlastnictví procesu Operations. Proto je tomuto procesu v průběhu celého textu věnována největší pozornost.
4.1.
Příprava projektu ICTIM
Tato podkapitola rozvede výše uvedené důvody vzniku projektu ICTIM a seznámí nás s posláním (misí), přínosy, cíly, rozsahem a záběrem, zdroji, riziky projektu, jeho fázemi a harmonogramem (viz Příloha #2). Kapitola 4.2 nazvaná Operations nás provede jedním z procesů ICTIM a ukáţe jej v detailu, od návrhu po zavedení do pilotního provozu.
18
K tomu, jak se to nakonec povedlo, se ještě v rámci této práce vrátím
~ 32 ~
4.1.1. Poslání „Posláním projektu je zahájit budování: takového systému řízení infrastruktury IT (vztahů mezi jednotlivým procesy, organizačními sloţkami a externími spolupracujícími organizacemi), který neodvratně povede k optimalizaci plnění zájmů svých vlastníků a potřeb zákazníků19 a umoţní reagovat na změnu zájmů vlastníků bez nutnosti úprav procesů a vztahů. systému řízení, který zaručí, ţe oblast ICT infrastruktury je řízena standardně, je trvale plánovaně zlepšována a tato zlepšení se promítají do zvyšování efektivity, jeţ sleduje, měří a prokazuje systém měření procesní výkonnosti prostřednictvím finančních i nefinančních ukazatelů”20.
4.1.2. Přínosy Vzhledem k programu SIP a jeho projektům vytváří projekt ICTIM „výrobní základnu“ pro IT Service Management. To se projeví zejména v níţe uvedených silných přínosech projektu ICTIM vůči jednomu z projektů SIPu, který má za úkol připravení SLA pro TOP 10 aplikací: Z krátkodobého hlediska dekompozice sluţeb (na něţ mají být uzavřena SLA) na standardní komponenty sluţeb21 zajištěné OLA, respektive UC stanovení a zajištění podílu procesů ICTIM a dalších procesů v gesci ORI na výrobě a dodávce sluţeb prostřednictvím dodávky komponent sluţeb stanovení nákladů procesů ICTIM a dalších procesů v gesci ORI na výrobě a dodávce sluţeb
19
Je vţdy dobré přesně identifikovat zákazníka. V tomto případě to byl nejenom business, ale i IT samotné neboť je naprosto nezbytná i podpora pracovníků například úseku vývoje IT 20 Citace z interního dokumentu – stylisticky a vzhledově upraveno [10] 21 Komponenty sluţeb – základní, pokud moţno standardizované a komoditní základní prvky, z nichţ se sluţba skládá. Někdy označované také jako infrastrukturní sluţby (Infrastructure Services)
~ 33 ~
Z dlouhodobého hlediska Dlouhodobé řízení kvality poskytovaných sluţeb je závislé na správném řízení rozvojových a optimalizačních aktivit v oblasti IT infrastruktury, tj. na schopnosti infrastruktury včas reagovat na změny poţadavků zákazníka na strukturu a kvalitu sluţeb dlouhodobě správným nastavením „výrobních linek“ pro jejich výrobu. Vůči ostatním procesům řízení ICT, které nejsou programem SIP aktuálně řešeny, naváţí procesy ICTIM standardní vazby dle míry rozvinutosti těchto procesů a moţností vzájemné spolupráce.
4.1.3. Cíle Cílem projektu je vytvořit standardní systém řízení IT infrastruktury dle ITIL tak, aby byl nastartován trvalý program zlepšování a zvyšování efektivity této oblasti IT: trvale zlepšovat vztah k zákazníkům infrastruktury rychlostí dodávky výstupů a jejich kvalitou trvale zlepšovat procesy řízení infrastruktury optimalizací procesního toku a odstraňováním nevhodné variability a neshod prokazovat dosahování těchto cílů systémem řízení procesní výkonnosti pomocí finančních i nefinančních parametrů Konkrétní měřitelné cíle budou určeny v rámci Fází 2 (quickwins) a 5 (dlouhodobé cíle). Záměrem je vykazovat kromě interních metrik i celkové metriky Balanced Scorecard, u kterých budou ve Fázi 2 a 5 identifikovány konkrétní metriky, na které má ICTIM přímý vliv.
4.1.4. Rozsah a předmět Rozsah projektu je určen následujícími procesy (viz Tabulka 1) a nutností zajištění jejich vstupů od dodavatelů (okolních procesů a organizačních jednotek) a zájmem nabídnout jejich výstupy zákazníkům, tedy okolním procesům a organizačním jednotkám. potřebou procesy a jejich vazby navrhnout a implementovat do běţného provozu ~ 34 ~
nutností promítnout navrţený systém řízení do oficiální řídící dokumentace organizace nutností, v rámci projektu, připravit navazující plán trvalého zlepšování a systém měření procesní výkonnosti Předmětem projektu je návrh a implementace těchto procesů do úrovně běžného provozu Tabulka 1 „Procesy řešené projektem č. 10“
Proces (zkratka) Rodina procesů Design & Planning (D&P) ICT Infrastructure Management Deployment (Dep) ICT Infrastructure Management Technical Support (TS) ICT Infrastructure Management Operations (OPs) ICT Infrastructure Management Capacity management (CaM) Service Delivery Configuration Management (CfM) Service Support Supplier Relationship Management (SRM)Business Perspective Zdroj: autor Jak je z předcházející tabulky patrné, kromě procesů Infrastructure Managementu byly zahrnuty do projektu také procesy z ostatních oblastí ITILv2. Zatímco SRM byl navrhován od začátku, procesy CaM a CfM byly původně součástí programu SIP a poté převedeny rozhodnutím projektového manaţera pod projekt ICTIM. Tento přístup nebyl na škodu, spíše naopak neboť došlo k lepšímu propojení a nastavení rozhraní všech výše uvedených procesů.
4.1.5. Konkretizace přípravných kroků Definice vizí a strategií pro realizaci daných procesů cíle zavedení/úpravy systému řízení IT metriky naplňování cílů projektu IT měření hodnot metrik analýza výchozího stavu a stanovení cesty k naplnění vize/strategie vytvoření/popis hodnotového řetězce dané procesní oblasti firmy a odpovídajícího systému měření procesní výkonnosti
~ 35 ~
risk analýza Definice zvolených procesů, včetně jejich vzájemných vazeb návrh
zvolených
procesů
dle
standardu
ITIL,
respektive
ISO
20 000
přizpůsobených konkrétním potřebám organizace vyuţití dalších metodik pro testování správnosti návrhu (např. Lean, Six Sigma, 8kroků změny) Poznámka: ISO 20 000 dává silná doporučení i pro procesy, kterými se jmenovitě nezabývá, např. pro ICTIM. Definice rolí procesní role, jejich pravomoci, odpovědnosti, KPI vztah procesních rolí a pracovních pozic Definice požadavků na SW a další podpory procesů a rolí stanovení poţadavků na SW podporu procesů, pro řízení a pro výkon stanovení poţadavků na normativní podporu procesů stanovení poţadavků na non SW materiální vybavení procesů Definice zanesení výstupů projektů do interních podnikových norem na straně oblasti řízení infrastruktury a svěřených procesů na straně okolních procesů v roli dodavatelů a zákazníků Vytvoření harmonogramů pro návrh i implementaci do provozu22 rozčlenění projektu do fází určení věcných vazeb určení časových sousledností Řízení projektů 22
Viz Příloha #2
~ 36 ~
sluţby řízení projektu Školení školení projektového týmu školení ostatních kooperujících pracovníků školení klíčových hráčů
4.1.6. Fáze projektu a jejich výstupy Nyní bude následovat popis jednotlivých fází projektu a jejich výstupů. Detailní harmonogram je součástí přílohy a jsou v něm zaneseny fáze včetně dat a milníků předpokládané realizace. Tento harmonogram byl pak aţ na naprosté výjimky dodrţen (do data finalizace diplomové práce). Fáze 0: Organizační zajištění projektu Projednání organizačního zajištění projektu cíle a očekávání od projektu koordinace s programem SIP risk analýza harmonogram projektu Change management dokument management schválení příslušným managementem Fáze 1: Školení Zahájení projektu, školení projektového týmu, školení top managementu IT členové projektového týmu vyškoleni pro realizaci projektu o základní školení ITIL – Foundation 3dny (3rd party)
~ 37 ~
o školení speciální ICTIM
školení příslušeného procesu
školení návrhu a implementace procesu – provedení organizační změny
top management seznámen s cíli a způsobem realizace projektu Fáze 2: Návrh standardního systému řízení Návrh architektury nového systému řízení (celkový procesní model). Na něj navazuje návrh cílového stavu jednotlivých procesů, jejich aspektů a vzájemných vazeb popis procesů popis vztahů mezi jednotlivými procesy popis rolí definice nástrojů pro jednotlivé role a procesy – SW a ostatní Fáze 3: Změření současného stavu optikou nového systému řízení Posouzení současného stavu systému řízení na základě znalosti nového cílového stavu. Změření „delty“ mezi současným a cílovým stavem pro celkový procesní model a pro jednotlivé procesy. analýza výchozího stavu a stanovení cesty k naplnění vize/strategie risk analýza „delty“ vůči cílům projektu plán krátkodobých vítězství pro první fázi projektu Fáze 4: Návrh plánu trvalého zlepšování Vytvoření první verze plánu trvalého zlepšování na základě znalosti rozdílu mezi současným a cílovým stavem. Plán trvalého zlepšování dále respektuje poţadavky na management ORI a úkoly v oblasti zvyšování efektivity a výkonnosti plán trvalého zlepšování ORI jako celku plány trvalého zlepšování procesů ~ 38 ~
plán krátkodobých vítězství zařazeny do plánu trvalého zlepšování Fáze 5: Návrh systému měření výkonnosti Vytvoření první verze systému měření procesní výkonnosti prostřednictvím finančních a nefinančních parametrů. Vytvoření/dokončení reportingu procesů. návrh systému měření výkonnosti návrh ABC23 systému pro řízení nákladů a jejich přiřazení výkonům v krátkém období (při jiţ stanoveném rozpočtu v běţném fiskálním roce) reporting procesů doplnění plánů trvalého zlepšování o měření a prokazování systémem měření výkonnosti a reportingem Poznámka: nutnost vyřešit kooperaci se současným controllingem IT. Fáze 6: Vytvoření řídící dokumentace nového systému řízení Vytvoření první verze řídící dokumentace nového systému řízení, která bude legalizovat zatím pouze „na papíře“ navrţený nový systém řízení, plán trvalého zlepšování procesní výkonnosti, řízení nákladů. Vypořádání původní řídící dokumentace legalizující původní (opouštěný) stav. řídící dokumentace procesů, plánů zlepšování, reportingu, měření výkonnosti, stand - alone controllingového modelu vypořádání původní řídící dokumentace legalizace a publikace nové řídící dokumentace Fáze 7: Příprava nasazení nového systému řízení „do provozu“ Příprava prvního release nového systému řízení – změna od původního chování a řízení k novému systému řízení dle nové řídící dokumentace plán implementace nového systému řízení
23
Viz Příloha #1
~ 39 ~
plán školení a jejich provedení úprava nástrojů přidělení zdrojů ORI novému systému řízení (soulad organizační struktury s novým procesním řízením) Fáze 8: Zahájení pilotního provozu nového systému řízení První release nového systému řízení – zahájení provozu nového systému řízení dle nové řídící dokumentace nový systém řízení v pilotním provozu dle nové řídící dokumentace Fáze 9: Vyhodnocení pilotního provozu, zahájení zvyšování efektivity a výkonnosti dle programu trvalého zlepšování, příprava nových změn Vyhodnocení výsledků pilotního provozu nového systému řízení. Naplánování nutných korektur a nových moţných změn a zlepšení. Kontrola business case a návrh projektu zvyšování efektivity a výkonnosti vyhodnocen pilotní provoz navrţeny korektury plánů zlepšení doplnění nových moţných změn a zlepšení kontrola naplnění business case a výpočet dosavadního ROI (daného zatím pouze krátkodobými zlepšení) Navrţen projekt zvyšování efektivity a výkonnosti (v souladu s plánem zlepšení nebo jeho update) o ihned provozovatelné k datu; do 1 měsíce; do 3 měsíců; do 12 měsíců plán přechodu od ABC k ABM k novému fiskálnímu roku plán zhodnocení investice do systému řízení – uvolnění nevyuţitých kapacit, zvýšení objemu a kvality výstupů
~ 40 ~
4.1.7. Organizace projektu Řídící výbor „Řídící výbor je vrcholovým rozhodovacím orgánem v průběhu realizace projektu. Úlohou řídícího výboru je v úvodní fázi projektu zejména definovat a odsouhlasit cíle, obsah, rozsah, rozpočet a termíny projektu, strukturu a sloţení týmů, standardy komunikace, pravomocí a odpovědností všech členů týmů, kteří se podílejí na realizaci projektu”. V průběhu realizace projektu pak tento výbor zodpovídá zejména: za jmenování a úkolování členů projektových týmů za sledování a kontrolu stavu plnění cílů projektu, plánu milníků a rozpočtu projektu za schvalování zásadních změn projektu (rozsah, obsah, cíle, termíny, náklady) za řešení zásadních konfliktů a sporů v nejvyšších strukturách projektu za uvolňování výsledků projektu ke zveřejnění Členové řídícího výboru měli svým vedením dánu kompetenci rozhodovat v zásadních otázkách realizace projektu a tato rozhodnutí směli prosazovat v celé organizační struktuře organizace. Členové řídícího výboru jsou: Sponzor projektu (současně předseda řídícího výboru): vrchní ředitel útvaru provozu IT – VŘ ÚPIT Sponzor projektu byl informován o průběhu projektu a ovládal projekt prostřednictvím řídícího výboru. Vrchní ředitel útvaru vývoje IT – VŘ ÚVIT Vedoucí projektu za předmětnou organizaci
~ 41 ~
Vedoucí projektu a jeho zástupce (současně vlastník procesu D&P) plnili zastřešující roli pro všechny navrhované procesy a měli právo do nich jakýmkoliv způsobem zasahovat24 (a tohoto také občas vyuţili). zástupce SIP Vedoucí projektu za stranu externí (vedoucí projektu II): externí konzultant25. Vedoucí projektu za stranu externí měl odpovídat za průběh prací v rámci schválených cílů a rozsahu smlouvy a dále měl zodpovědnost za dodrţování termínů dle schváleného časového harmonogramu. Dále pak detailně plánoval, koordinoval a kontroloval všechny aktivity na své úrovni řízení a ukládal úkoly členům projektového týmu. Psaní zápisů z jednání byla jeho další povinnost. V součinnosti s vedoucím projektu schvaloval poţadavky na změny (tzv. RfC), které ovšem neměli zásadní vliv na cíle a rozsah, časový plán, rozpočet a kvalitu projektu. Koordinoval činnosti projektu, které měli vztah k organizaci a lidským zdrojům zákazníka a měl oprávnění navrhnout změny sloţení týmů (toto právo však za dobu svého působení nevyuţil). Projektový tým „Členové projektového týmu se podílejí na realizaci projektu formou a v termínech uvedených základním způsobem v harmonogramu projektu a dále upřesněných závěry z jednání projektového týmu, respektive řídícího výboru. Členové projektového týmu zabezpečují vlastní projektové řešení v příslušné oblasti. Tito členové jsou jmenováni řídícím výborem na základě návrhu Vedoucího projektu”. Následuje jejich výčet včetně toho, zda mají zástupce. Vedoucí projektu a jeho zástupce Vlastník procesu Design and Planning (D&P) a jeho zástupce Vlastník procesu Deployment (Dep) a jeho zástupce 24
ICT Infrastructure Management není vlastně proces sám o sobě. Proto ani neměl jako takový navrţeno vlastní workflow. Do toho by typicky spadaly poţadavky na vlastníky procesů 25 V kapitole 1.1 jsem se zmiňoval o šetření finančních prostředků. Zde došlo k úsměvnému poţadavku ze strany organizace v době, kdy tomuto konzultantovi zbývalo na projektu pouze pár man-dayů. Nešlo ani tak o to, ţe byl poţádán těchto řádově do 10ti man-dayů ještě zkrátit ale o to, ţe byl dotázán, zda-li by „z přátelství” nebylo moţné zpětně sníţit cenu za jím poskytnuté sluţby! On to samozřejmě odmítl (viděli se poprvé)
~ 42 ~
Vlastník procesu Technical Support (TS) a jeho zástupce Vlastník procesu Operations (OPs) – autor. Bez zástupce Vlastník procesu Configuration Management (CfM). Bez zástupce Vlastník procesu Capacity Management (CaM) a jeho zástupce Vlastník procesu Supplier Relationship Management (SRM). Bez zástupce Vedoucí projektu za stranu externí Vedle těchto lidí spolupracovalo ještě několik dalších, ale tito neměli stanoveny speciální role ve fázi návrhu. Byli na pravidelné schůze zváni pouze občas a v rámci konzultací za konkrétní oblasti infrastruktury. Jak je dále vidět, někteří vlastníci procesů neměli stanovené zástupce, ač o ně dokonce opakovaně, ţádali! Toto je jedna z mých velkých výhrad, o které bude ještě pojednáno v závěrečné části. Administrátor projektu Administrátor projektu byl pověřen organizováním schůzek řídícího výboru a projektového týmu - pozvánky, místo, materiální zabezpečení. Tyto schůzky nebyly společné. Dalším úkolem byla distribuce zápisů z jednání členům Projektového týmu, vedení evidence těchto zápisů a archivace veškerých výstupů (co se správy projektu týče, nikoliv výstupů jednotlivých procesů, které byly v jejich rámci navrţeny).
4.1.8. Rizika Protoţe projekty 1 – 9 programu SIP probíhaly částečně současně a tedy v překryvu, jednalo se nedostatek zdrojů a tedy moţné potíţe s jejich alokací. Problém se mohl vyskytnout u: osob, které se podílely na více projektech a mohlo tak docházet (a docházelo) ke kolizím v termínech pravidelných porad (toto není dáno špatnou mezi-projektovou komunikací mezi jednotlivými týmy ale tím, ţe projekt č. 10 nastartoval se značným časovým odstupem a jiţ nezbyl prostor v kalendářích účastníků, protoţe se jednalo o vytíţené pracovníky na manaţerských postech) ~ 43 ~
klíčových zdrojů z důvodu jejich nedostupnosti nebo přetíţení. V projektu č. 1 totiţ došlo ke zformování ServiceDesku, coţ si vyţádalo nemalý úbytek pracovních sil, které by byly potřeba při provozování infrastruktury K minimalizaci těchto rizik byl proto nutný monitoring kapacit klíčových zdrojů a stanovení jasných priorit při jejich alokacích.
4.2.
Návrh a implementace procesu Operations
Na tomto místě bych rád čtenáře seznámil s konkrétním návrhem procesu Operations tak, jak vstoupil do fáze pilotního provozu. Popis bude strukturován podle fází uvedených v kapitole 4.1.6. a pokud došlo k nějakým odchylkám od plánovaného, bude to zmíněno a odůvodněno. Jiţ teď předběhnu a mohu konstatovat, ţe byl následující návrh funkční, a i kdyţ byly pro další fázi stanoveny korekční kroky (mimo těch, které nebyly zahrnuty do prvního releasu vůbec), charakterizoval bych je spíše jako kosmetické a lépe odráţející prostředí organizace. Je to i logické neboť jsem před tímto projektem s podobnými aktivitami neměl zkušenost a tak byl návrh tvořen silně dle doporučení ITILu a nebyl příliš konfrontován realitou ve společnosti. Poznámka: Proces Operations je kritický a nepostradatelný. Zabývá se provozem infrastruktury, která je jen po hardwarové stránce úctyhodná (přes 1000 serverů, stejný počet aktivních prvků, kolem třiceti diskových polí a další HW jako klimatizace, UPS a jiné).
4.2.1. Fáze 0: Organizační zajištění projektu Tuto fázi uvádím pouze pro úplnost. Zde jsem jako řešitel nijak nefiguroval a původně nebyl do projektu zahrnut vůbec. K tomu došlo aţ dodatečně v průběhu Fáze 1 z důvodu mého zájmu o participaci na projektu, který byl vyslyšen.
4.2.2. Fáze 1: Školení Někdy během této fáze (nelze říci přesně, neboť jsem o existenci projektu neměl tušení) došlo k setkání celého Odboru rozvoje infrastruktury (dále jen ORI). Zde byly představeny úmysly vedení a důvody, které k nim vedly. Tím bylo, pro připomenutí, zavedení procesního řízení v rámci ORI. Tyto záměry se nesetkaly s příliš kladným ohlasem a mám ~ 44 ~
pocit, ţe ani lidé nevěděli, o co přesně jde. Tuto nevoli bych přičetl k tomu, ţe se řady zaměstnanců jiţ dotkly aktivity vycházející z programu SIP 1-9 a tyto byly spojeny s nárůstem byrokracie - „papírováním” jak je s oblibou zaměstnanci označována. Na tomto místě bych se však lidí „z provozu” rád zastal (nejen proto, ţe jsem byl a dosud jsem jedním z nich). Zavádění procesů ITILu26 s sebou nese vţdy nárůst formálnosti vztahů při předávání informací a jiných souvisejících aktivitách. Tím pádem dochází k nárůstu oné byrokracie, která v určitých případech vyvolává aţ odpor. V IT útvarech je potom tento fakt zřetelný více neţli v oddělení jiných a se dá přisoudit tomu, ţe IT vţdy fungovalo na ne příliš formální bázi. Na konci setkání (viz první odstavec) byla učiněna nabídka školení případných zájemců včetně jejich aktivní účasti při návrhu procesů. Já jsem na tuto příleţitost zareagoval a do týdne přišla nabídka na vlastnictví procesu Operations. Následovala akceptace z mé strany a zaškolení. Školení bylo jednodenní a spočívalo v představení ITILu v2 plus Infrastructure Managementu v dopoledních hodinách a v těch odpoledních byl pak podrobněji přednesen proces Operations samotný (dle školitele šlo o tzv. „komentované čtení” – předčítání z knihy Infrastructure Managementu s vysvětlením nejasných pasáţí). Zde můţeme vidět první odchylku od plánovaného, kde bylo počítáno s třídenním kurzem ITIL Foundation vX27. K ní nedošlo ani tak z finančních důvodů zmiňovaných dříve v textu, ale z těch časových (protoţe jsou tato školení organizována specializovanými firmami a pro předem stanovené počty zájemců) a zde nás jiţ tlačil čas a bylo nutné se vejít do harmonogramu. Navíc ITIL Foundation představuje přehled a souvislosti všech procesů ITILu a blíţe se zaměřuje na Service Support a Service Delivery (u v2). Pro proces Operations a procesy pouze ICTIM jsem adekvátní školení v nabídkách firem (například firmy HP) nenašel a tak byla zvolena výše uvedená varianta komentovaného čtení, které muselo být, kvůli rozsahu problematiky, doplněno výrazným samostudiem. Někde na přelomu Fáze 1 a Fáze 2 jsem si poloţil otázku, co to vlastně ta infrastruktura je (její hranice). Otázka mi přišla logická a zprvu jsem se dokonce ostýchal ji poloţit nejen školiteli, ale posléze i vedení projektu. Nedalo mi to, dotaz jsem učinil a jaké bylo mé 26
Ale nejen jich. Dochází k tomu i při zavádění bezpečnostních a jiných opatření, která do té doby nebyla implementována 27 X zastupuje verzi. V nabídkách se nyní objevují v2 a v3. Certifikace lze vykonat v současné době uţ ale pouze na verzi 3
~ 45 ~
překvapení, kdyţ se mi dostalo nejen rozdílných, ale i nejasných odpovědí. V pilířích se tyto odpovědi shodovaly, ale k nejasnostem došlo vţdy v otázkách rozhraní mezi infrastrukturou a aplikací28. Proto jsem vyplnil RfC (bylo dokonce patřičně oceněno pro největší přínos ve fázi návrhu procesů), jehoţ výstup měl hranici stanovit. Toto stanovení jsem si určil jako tzv. quickwin (viz slovník). Zde došlo trochu k nedorozumění, protoţe jsem se později dozvěděl, ţe si to vzal za své i vlastník procesu Design and Planning. Nakonec jsme se domluvili a následuje výňatek z oficiálního dokumentu, který na toto téma vznikl (v upravené struktuře pro potřeby diplomové práce, citace jsou vedeny v uvozovkách). Definice infrastruktury obsahuje tři pohledy: technologický pohled a pohledy z hledisek správy a rozsahu. Protoţe ne celá infrastruktura byla řešena projektem č. 10, bude tato skutečnost u kaţdé části explicitně zmíněna. I.
Definice technologická
„Infrastrukturou se rozumí níţe uvedené technologické oblasti. Vše mimo níţe uvedený výčet je povaţováno za aplikaci, nebo sluţbu. Všechny prvky infrastruktury jsou evidovány v CMDB”. HW (fyzická infrastruktura): Tabulka 2 „Provozovaný HW“
Provozovaný (spravovaný) HW sály / serverovny a jejich vybavení UPS / klimatizace / racky sítě/síťové prvky / síťové vedení / telefonie / bezpečnostní perimetr servery storage / disková pole pracovní stanice / PC Zdroj: autor
Řešeno projektem č. 10 ne ano ano ano ne
Operační systémy (všechny řešeny Projektem č. 10) Platformy (domény, instance)
28
Tuto hranici bylo nutno stanovit protoţe Infrastructure Management by se měl zabývat pouze řízením infrastruktury a pro řízení Aplikací a vše okolo nich je v rámci ITILu v2 navrţena jiná skupina procesů a sice procesů Aplication Managementu
~ 46 ~
Tabulka 3 „Provozovaný aplikační server / framework“
Provozovaný (spravovaný) aplikační server / framework OAS BEA JBOSS Zdroj: autor
Řešeno projektem č. 10 ano ano ano
Tabulka 4 „Provozovaná databáze“
Provozovaná (spravovaná) databáze Oracle DB2 MS SQL Zdroj: autor
Řešeno projektem č. 10 ano ano ano
Infra systémy Tabulka 5 „Provozovaný infra systém“
Provozovaný (spravovaný) infra systém monitoring (centrální, nikoliv „udělátka“ konkrétních správců) backup (centrální zálohování) Zdroj: autor
Řešeno projektem č. 10 ne ano
„Správou infrastruktury se rozumí správa fyzických zařízení (umisťování, stěhování, údrţba), konfigurace jejich parametrů a provoz těchto zařízení a systémů (monitoring, provozní úkony)”. II.
Definice z hlediska správy
„Všechny prvky infrastruktury jsou spravovány centrálně. Prvky infrastruktury jsou z hlediska provozování rozděleny do skupin dle níţe uvedených technologických kategorií. Správa kaţdé skupiny infrastruktury se řídí obdobnými pravidly, jsou technologicky blízké a zajišťuje ji skupina lidí se znalostmi dané oblasti”.
~ 47 ~
Tabulka 6 „Návrh Management Domains procesem D&P versus návrh vlastníkem Operations“
Navrhované Management Domains (MD) vlastníkem D&P sály / serverovny a jejich vybavení UPS / klimatizace / racky sítě / síťové prvky / síťové vedení / telefonie / bezpečnostní perimetr servery + operační systémy WINTEL servery + operační systémy UNIX (SUN, IBM, LINUX) servery + operační systémy MAINFRAME storage / disková pole
pracovní stanice / PC aplikační servery / frameworky (OAS, BEA, JBOSS) databáze (Oracle, DB2, MS SQL) infra systémy monitoring infra systémy backup Zdroj: autor
Navrhované Management Domains (MD) vlastníkem Operations irelevantní - viz Tabulka „Provozovaný HW“
rozděleno na tři MD: síťová infrastruktura; telefonie + kontaktní centrum; bezpečnostní perimetr shoda s D&P (pouze vyčleněny technologie webových farem a tiskových systémů) jako samostatné MD pro OS typu UNIX (Solaris, Aix, RedHat) byly MD stanoveny zvlášť shoda s D&P SAN infrastruktura spadala pod stejnou MD jako OS Solaris. Ostatní „storage systémy" pak pod MD příslušných platforem Irelevantní - viz Tabulka „Provozovaný HW“ shoda s D&P každé z databází byla vyčleněna samostatná MD Irelevantní - viz Tabulka „Provozovaný infra systém“ shoda s D&P
Jak je vidět z předchozí tabulky, stanovil jsem si MD odlišně od toho, jak navrhl vlastník D&P. Je to v pořádku, neboť on je navrhoval z pohledu celé organizace a předurčoval směr, jak by to v budoucnu mělo správně být. Já jsem členění v rámci Operations prováděl podle zkušeností lidí, kteří danou část infrastruktury provozovali. Rovněţ jsem byl limitován provozováním infrastruktury, která spadala pod odbor ORI (toto je konkrétní příklad, kde jsem narazil na kompetenční neshodu organizační struktury a procesu) a tím jsem byl nucen vyčlenit systémy centrálního monitoringu, oblast pracovních stanic a vybavení serveroven (jiné neţ servery, aktivní prvky, disková pole, konzole) a dál se jimi nezabývat. III.
Definice z hlediska rozsahu
„Za infrastrukturu řízenou ICTIM procesy se povaţují prvky produkčního prostředí (evidované v CMDB) a dále všechny ostatní prvky / prostředí, na která je uzavřeno OLA s vlastníkem procesů ICTIM”. ~ 48 ~
4.2.3. Fáze 2: Návrh standardního systému řízení29 Fáze Návrh standardního systému řízení byla zahájena základním popisem jednotlivých procesů. Pro tento účel si manaţer projektu vypůjčil takzvaný SIPOC diagram z metodiky Six Sigma. Důvod byl ten, ţe „best practice” ITIL neumí implementovat sám sebe a pro návrh se lépe hodí jiné nástroje. Výstupy procesu jsem navrhl podle ITIL v2. Vstupů jsem si potom stanovil skutečně mnoho a pro ukázku uvedu pouze ty, které nabízely procesy řešené Projektem č. 10. S výstupy ostatních procesů ze SIPu 1-9 jsem jako se vstupy pro můj proces nemohl stoprocentně počítat, proto je zde vynechám. Po Misi a Cílech následuje avizovaný SIPOC diagram. Mise: Zajistit stabilní a bezpečný provoz ICT infrastruktury a kvalitní dodávky ICT služeb. Cíle: Zabezpečit robustní, spolehlivou a bezpečnou ICT infrastrukturu. Kvalitní a efektivní podpora business procesů dodávanými ICT službami a dodržováním všech dohodnutých smluv (OLA).
29
Kurzívou dále v oddíle Fáze 2… označeny ty charakteristiky, které jsem navrhl pro proces Operations a které byly později zaneseny do řídící dokumentace
~ 49 ~
Tabulka 7 „SIPOC diagram procesu Operations navrţeného v projektu č. 10“
S
I
P
O
C
Suppliers
Inputs
Process
Outputs
Customers
Současná ICT infrastruktura
TS
Dep
SRM
CfM
CaM
Strategie, politiky, plány, standardy, návrhy ICT infra řešení 1) Analýzy a doporučení:
provozní dokumentace, účast na nasazení změn infrastruktury, podpora rozvoje architektur a plánů, návody k použití a odstranění závad CI, testování CI, analýzy použitelnosti CI, doporučení využití CI 2) Řešení incidentů a problémů 1) ICT řešení uvedené do provozního stavu 2) Plán uvedení řešení do provozního stavu 3) Dokumentace, návody, postupy 4) Informace a zaškolení pro novou infrastrukturu 1) Databáze uzavřených UC 2) Databáze dodavatelů 3) Hodnocení dodavatelů (provozní) 4) UC/SLA s vhodným obsahem 1) CMDB 2) Definice pojmu CI 3) Pravidla užívání CMDB 1) Monitoring kapacit 2) Plán vývoje kapacit 3) Databáze kapacit 4) Prahové hodnoty, alarmy 5) Report využití kapacit 6) Tvorba kapacitních a výkonových doporučení (optimalizace, předcházení/řešení incidentů a problémů, změn)
Procesní kroky. Viz WORKFLOW
D&P
Provozní reporting
ICTIM
Informace o výkonech dodavatelů
SRM
Knihovna provozní dokumentace
TS
Databáze odchylek od provozních standardů
D&P, TS, SRM, CapM
Informace z dohledových systémů
TS, CapM
Provozní skripty, plány a procedury
D&P, TS, Dep, CapM
Zdroj: autor
~ 50 ~
Ke stanovení vstupů a výstupů (včetně zákazníků a dodavatelů) procesů proběhla burza, která měla tři kola. Ta spočívala v tom, ţe všichni vlastníci procesů sepsali výstupy svých procesů, které by chtěli a mohli dodávat. Poté se doţadovali vstupů, které tvořily právě výstupy z okolních procesů. Tak vznikla matice, která byla ještě dvakrát projednána. Kaţdý měl své výstupy pečlivě popsány (obsah, znaky kvality, forma, připravenost k dodání k určitému datu, způsob vytvoření) čímţ byla zajištěna jejich kvalita a datum vzniku a tak mohl kaţdý počítat jejich dodávkou. S odstupem času a pro větší zkušenosti (i z pilotního provozu) mohu nyní konstatovat, ţe jsem si alokoval příliš mnoho vstupů, které ani nevyuţívám. Naštěstí to nijak nevadí a vstupy zkrátka nepoţaduji a nikdo mi je ani nenutí. Workflow30: Workflow (WF) procesu jsem si stanovil takto (viz Obrázek 7 „Workflow procesu Operations…“). Nejprve jsem je měl uděláno pouze pro účely procesu Operations jako takového a tedy pro produkci výstupů vzniklých provozem systémů. V rámci ladění vytvořených workflow31 došlo k zadání z vedení projektu, aby kaţdý vlastník dodělal do jeho WF větev s poţadavkem na vlastníka procesu. To bylo učiněno proto, ţe zastřešující „proces“ ICTIM jako takový neměl ţádné vlastní workflow a poţadavky na jednotlivé vlastníky musely jít tedy přes jejich vlastní. Popis poloţek: Krok SIPOC: tento sloupec popisuje blokové schéma procesu tak, jak bylo navrţeno v základním popisu procesu. Nikde výše není uvedeno, ale patřilo by do třetího sloupce „P“ v Tabulce 7 „SIPOC diagram procesu Operations…“. ID kroku: pod tímto sloupcem se skrývají konkrétní ID procesních kroků. OPs označuje zkratku procesu Operations a za ním následující číslo nese jedinečnou identifikaci kroku. Začátky ID 2,4,6 značí, do jakého bloku činností konkrétní krok patří. Krátký popis kroku: slovní popis kroku WF tak, jak je zobrazován i v nástroji pro podporu řízení procesu.
30
Viz slovník pouţitých pojmů a zkratek v příloze 1 To se ladilo při tzv. manaţerských hrách, které spočívaly v testování navrţených workflow a jiných aspektů procesů. Pomohly odhalit spoustu nedokonalostí 31
~ 51 ~
Vykonavatel kroku: zde jsou uváděny procesní role vykonávající krok WF. V tomto případě platí, ţe kaţdý krok WF můţe být vykonáván právě jednou procesní rolí (OWN – Vlastník procesu; MPR – Manaţer provozu; APL – Analytik plánování provozu; ADM – Administrátor). Číslo normy detailně popisující krok: sem patří popis jednotlivých kroků WF. Na obrázku tento sloupec nic neobsahuje, neboť tyto normy nebyly pro první release vytvořeny. Pravidlo funkční eskalace: toto pravidlo vyjadřuje podmínku, za které můţeme v rámci procesu přejít k dalšímu procesnímu kroku. ID navazujícího kroku: na tento krok se přejde v případě, ţe je splněna podmínka uvedená v předchozí odráţce. Pravidla hierarchické eskalace: obsah kroku udrţuje informaci o tom, na koho se obrátit v případě, ţe není (nemůţe být) dodrţeno Pravidlo funkční eskalace (TS XXX – proces Technical Support a číslo příslušného kroku v jeho procesu; Migrace – v organizaci představuje funkci Release Managementu). Pro další release plánuji pár změn WF. Není to ani tak z důvodu, ţe by bylo nevyhovující (coţ u pár procesů nastalo), ale kvůli nadbytečnosti některých kroků, které nevyuţívám. Ještě nejsem plně rozhodnut, ale redukce se bude týkat pravděpodobně kroku OPs410.
~ 52 ~
Zdroj: autor
~ 53 ~
6XX Kontrola, hodnocení a reporting
4XX Realizace, administrace, údržba, správa
2XX Přijetí, plánování a koordinace úkolů a informací
Krok SIPOC
Realizace naplánovaných postupů a akcí
Kontrola, hodnocení a reporting
Kontrola a příprava na předání výstupu; případná tvorba reportu
Kontrola evidence a provozní reporting
OPs610
OPs620
OPs630
Řešení požadavků z ITG aj. ad hoc provozních úkolů; evidence zásahů
Provoz, správa a monitoring systémů
Součinnost (migrace,...); evidence zásahů
Řešení událostí nemajících povahu incidentu; evidence zásahů
OPs450
OPs440
OPs430
OPs420
OPs410
Plánování provozu / analýza
Požadavek na vlastníka procesu Operations
OPs240
Přiřazení řešitelů podle typu požadavku
Příjem, evidence a posouzení požadavků a vstupů do Operations z definovaných procesů, zevnitř procesu, ITG vč. ad-hoc úkolů od nadřízených a ICTIM.
Krátký popis kroku procesu
OPs230
OPs220
OPs210
ID kroku
MPR
OWN
MPR
OWN
ADM
ADM
ADM
ADM
OWN
APL
MPR
MPR
Vykonavate l kroku
Číslo normy detailně popisující krok
Plánování / analýza dokončeny
Kontrola evidence dokončena; reporty připravené k dodávce
Výstup popř. report je připraven k dodávce
Kontrola, hodnocení a reporting provedeny
Řešení pro zadavatele je k dispozici
Požadavek vyřešen, výsledek předán (resp. popis důvodu případného odmítnutí); evidence do provozního deníku provedena
Provoz, správa, monitoring systémů a zaznaménání skutečného času těchto aktivit provedeny
Součinnost provedena (vč. případné evidence zásahů)
Událost vyřešena (resp. popis důvodu případného odmítnutí); evidence do provozního deníku provedena
Požadavek analyzován a rozhodnuto o dalším postupu; naplánování akcí
Předání výstupu (Provozní reporting) - KONEC WF
(Předání výstupů) - KONEC WF
KONEC WF
OPs620
Předání výstupů (podle konkrétní povahy úkolu) OPs610
Předání výstupů (Stabilní a bezpečná infrastruktura; Info o výkonech dodavatelů; Knihovna provozní dokumentace; Info z dohledových systémů, DB odchylek od provozních standardů a Provozní skripty, plány, procedury) - OPs630
Předání výstupu (Stabilní a bezpečná infrastruktura) OPs610
Předání výstupu (Stabilní a bezpečná infrastruktura) OPs610
OPs450
OPs220
OPs440
OPs410
OPs430
OPs420
Požadavek na součinnost (migrace,...) Požadavek na administraci Požadavek na řešení události nemající povahu incidentu Řešení požadavků z ITG aj. ad hoc provozních úkolů
OPs240
OPs230
KONEC WF
OPs220
ID navazujícího kroku
Požadavek na vlastníka procesu Operations
Požadavek na plánování provozu / analýzu
Požadavek není určen procesu Operations popř. došlo k důvodnému odmítnutí řešitelem
Požadavek určen procesu Operations a vyhodnocen jako srozumitelný
Pravidlo funkční eskalace
N/A
N/A
N/A
N/A
MPR, TS XXX
MPR
MPR, Migrace (RM)
MPR, TS XXX
N/A
MPR
N/A
N/A
OWN
Pravidla hierarchické eskalace
Obrázek 7 „Workflow procesu Operations navrţené v rámci projektu č. 10“
Role: Následují odpovědnosti, systém vzdělávání a KPI kaţdé navrţené role. Vlastník procesu Operations Odpovědnosti (standardní povinnosti a odpovědnosti vlastníka procesu tak, jak byly popsány v kapitole 1.2.2.) Systém vzdělávání (VŠ; AJ; semináře a školení zejména v oblasti nových ICT na trhu; manažerská školení) KPI (Funkčnost celého procesu Operations; Ekonomické ukazatele procesu) Manažer provozu / vedoucí směny Odpovědnosti (Je odpovědný za řízení, koordinaci a kontrolu provozního personálu. Jim vedené lidi motivuje a rozvíjí, aby byli schopni plnit stanovené cíle tedy především SLA resp. OLA. To vše při dodržení stanoveného rozpočtu. Plánuje a sleduje zdroje. Spolupracuje s ostatními úseky IT) Systém vzdělávání (VŠ; AJ; semináře a školení zejména v oblasti nových ICT na trhu; manažerská školení) KPI (Definovaná dostupnost ICT infrastruktury a plnění služeb; Snížení počtu incidentů způsobených podřízenými zaměstnanci či jinou chybou respektive nedostatkem v procesu Operations) Analytik plánování provozu Odpovědnosti (Zajišťuje a je odpovědný za plánování všech provozních procesů a pracovních postupů, aby byly v souladu s plány a ujednáními v SLA resp. OLA. Úzká spolupráce s Change Managementem) Systém vzdělávání (VŠ/SŠ; vzdělávání a rozšiřování znalostí o používaných technologiích ve společnosti) KPI (Eliminace nekompatibilních nebo vylučujících se činností; Všechny provozní postupy a plány jsou hotovy a zdokumentovány, nekolidují)
~ 54 ~
Administrátor Odpovědnosti (Zajišťuje dostupnost, spolehlivost a výkonnost jemu svěřených HW a SW systémů. Spravuje uživatele a uživatelské profily, soubory a celé souborové systémy a příslušná zařízení. Toto dělá dle definovaných pravidel, postupů a rozvrhů. Dává podněty ke zlepšení a podílí se na vývoji automatizovaných nástrojů pro provoz. Cílem jeho práce je udržet úroveň nasmlouvaných služeb a provoz produkčních prostředí bez výpadků) Systém vzdělávání (VŠ/SŠ; AJ; semináře a periodická školení příslušných systémů jsou nezbytné) KPI (Dodržování pracovních postupů; Plnění zadaných úkolů a evidence zásahů) Poznámka: V procesním řízení platí, ţe jeden člověk můţe vystupovat ve více rolích buď v jednom procesu anebo i v rámci ostatních procesů. Není to tedy tak, ţe musí vystupovat pouze v jedné roli konkrétního procesu. Dále platí, ţe jedné roli smí být přiřazen libovolný počet zaměstnanců. Obsazení zaměstnanců ORI jsem navrhl tak, ţe byli všichni v roli Administrátor a současně Analytik plánování provozu, takţe mohli zastávat jakoukoliv z nich podle potřeby. Já jsem potom vystupoval ve všech výše uvedených rolích plus v rolích navrţených pro jiné procesy! ITIL v2 doporučuje vyčlenit role „zálohovače“ a databázového administrátora jako samostatné. Já jsem tohoto pro první release nevyuţil, protoţe by se mi workflow procesu pouze rozrostlo o dvě další větve, ale efekt by z toho nebyl ţádný – administrátorům stejně jdou ty samé poţadavky, jen kaţdému za jinou oblast jim svěřených systémů. Roli Analytik plánování provozu jsem navrhl na doporučení ITIL v2. V pilotním provozu jsem ji však téměř nevyuţíval, a proto uvaţuji o jejím zrušení pro následující release systému řízení. Nástroje. Nástroje jsou dvojího druhu. Jednak nástroje pro podporu řízení procesu (workflow nástroj32, MS Office, CMDB, reportingový nástroj, www stránky atd.) a za druhé konkrétní nástroje (jelikoţ jde o veliké mnoţství pouţívaných programů a jiného vybavení, 32
Naprogramován v průběhu návrhu procesů. I kdyţ to bylo nevyhnutelné, došlo tím ke zdvojení nástrojů pro vykazování práce coţ není nikdy dobře. Bude ještě uvedeno v závěrečné části jako jedna z výhrad
~ 55 ~
nebyl výčet uskutečněn i proto, ţe by se špatně udrţoval) administrátorů, které vyuţívají ke své práci v rámci produkce výstupů. Kultura: Provozovat ICT infrastrukturu a poskytovat ICT služby vždy v souladu s uzavřenými dohodami. Udržovat dobré vztahy nejen se zákazníkem, ale i s dodavateli a tyto vztahy neustále rozvíjet. Rozvíjet znalosti pracovníků procesu Operations a pozitivně je motivovat k výkonům, které zabezpečí opakované plnění stanovených cílů a mise celého procesu.
4.2.4. Fáze 3: Změření současného stavu optikou nového systému řízení Změření současného stavu vyspělosti procesu bylo čistě subjektivní a stanoveno podle mého, do té doby, dvouletého působení v organizaci. K měření byl vyuţit rámec PMF (Process Maturity Framework) a výstup byl následující: Tabulka 8 „Změření vyspělosti procesu pomocí PMF“
Aspekt procesu
Hodnocení dle PMF 1 1 1 2 2 1
Mise Systém řízení Workflow Lidé/Role Technologie/Nástroje Kultura
Zdroj: autor Poznámka: Hodnocení dle PMF (1 – Initial; 2 – Repeatable; 3 – Defined; 4 - Managed; 5 Optimized) Výše uvedené nelichotivé hodnocení jednotlivých aspektů je pochopitelné, neb do doby zahájení projektu nebyly nijak popsané. V době psaní této práce bohuţel nemohu posoudit a popsat současný stav (zda se hodnocení dle PMF někam posunulo), protoţe ještě nebyl ukončen a vyhodnocen pilotní provoz. ~ 56 ~
Risk analýza: Risk analýza rozdílu mezi současným a cílovým stavem. Kvůli rozsahu je tato součástí Přílohy #3. Poznámka: následující obrázek ilustruje postup risk analýzy a pod ním následuje vysvětlení pouţitých pojmů: Obrázek 8 „Postup risk analýzy (dle normy AS/NZS 4360:2004 Risk Management)“
Zdroj: Školící materiál firmy Win4all [11] Aktiva (pro nás jsou aktivy výstupy procesu Operations) – tvoří hodnotu nezbytnou k dosaţení cíle. Charakter a rozsah zkoumaných aktiv tvoří hranice analýzy rizik. Hrozby (ohroţují dodávku výstupů procesu) - jsou okolnosti nebo události, které mají potenciál zabránit nebo sníţit úspěšnost dosaţení cílů nebo přerušit proces k dosaţení cílů. Zranitelnost (říká, jaká je účinnost hrozeb na výstupy procesu) - ukazuje, nakolik se identifikované hrozby mohou projevit. Následky (následky nedodání výstupu procesu) - charakterizují dopad hrozeb a zranitelností, pokud se projeví. Riziko (míra pravděpodobnosti, uplatnění hrozby, tj. nedodání výstupu) - je funkce pravděpodobnosti
události,
kdy
se
pro
dané
aktivum
prostřednictvím zranitelnosti, a následků, které to přinese.
~ 57 ~
uplatní
hrozba,
Quickwiny33: Knihovna provozní dokumentace; Informace o výkonech dodavatelů Prvně jmenovaný quickwin, jímţ měl být stejnojmenný výstup řešen, byl stanoven příliš ambiciózně, a jak se ukázalo a jak to nyní chápu, jedná se o velice komplexní výstup s dobře propracovaným systémem návrhu a aktualizace. Nebylo tedy v ţádném případě moţné tento quickwin časově dodrţet. Navíc mám za úkol vybudovat respektive dát dohromady provozní dokumentaci prakticky od začátku. Jako taková buď neexistuje v současné době vůbec, nebo je roztříštěná po různě strukturovaných dokumentech u jednotlivých správců. Naproti tomu quickwin „Informace o výkonech dodavatelů“ spočíval pouze v domluvě s vlastníkem procesu SRM na formě a periodicitě předávaných dat. V tomto případě byl navrţen dokument se stupnicí (1-10), na které mají zaměstnanci provozu hodnotit pracovníky dodavatele. Ţádoucí je i slovní doprovod a zdůvodnění přidělených bodů. Periodicita pak byla stanovena 1x do měsíce (tedy maximálně 12 výstupů za rok a za konkrétního dodavatele) v případě, ţe budou konzultace či jiný zásah ze strany dodavatele provedeny.
4.2.5. Fáze 4: Návrh plánu trvalého zlepšování Plán trvalého zlepšování je dokument, který popisuje, jakým způsobem se lze dostat od současného stavu ke stavu cílovému. Obecně je to dokument, který je vyţadován například ISO 20000 a jeho auditory v případě, ţe bychom měli ambice procesy certifikovat34. Externí konzultant navrhl tento plán ve struktuře PDCA (Plan – Do – Check – Act) cyklu. Plan (Naplánování zlepšení - v našem případě plán releasů). Výstupem této fáze měl být plán na pět releasů dopředu, tedy do února r. 2010. Na tomto místě uvedu pro ukázku plán pro první release (R1). Zde jsem si dal za cíl začít poskytovat výstupy dle 4.2.3 a v definované kvalitě. Patřili sem i jiţ dříve zmiňované oddělení ICT infrastruktury od aplikace a rozdělení infrastruktury na logické celky Management Domains (MD).
33
„Krátkodobá vítězství“ Tady ale pozor. Tuto informaci jsem uvedl pro výklad toho, co PTZ je. Na procesy Infrastructure managementu se totiţ certifikace ISO 20000 nevztahuje. Vztahuje se na procesy IT Service managementu, Security managementu a některé další 34
~ 58 ~
Vše uvedené se povedlo aţ na další závazek „Způsob řízení, ověřování a zlepšování kvality výstupů bude navrţen na základní úrovni”. Tento nebyl dodrţen a byl přeplánován a bude implementován pro druhý release (R2). Úplný obsah navrhovaných změn pro R2 je popsán v kapitole 5. o pilotním provozu. Do (Provedení zlepšení – to, jakým způsobem bude naplánované řešení realizováno a jak bude měřena jeho úspěšnost. Například realizace projektem či pouze nějakým opatřením). Check (Kontrola funkčnosti řešení). V našem případě není relevantní, protoţe se jedná o první release. Act (Jak bude funkční řešení rozpracováno do definitivní podoby, do plného nasazení a uţívání). Nakonec byl plán „krátkodobých vítězství“ z předchozí fáze doplněn do Plánu trvalého zlepšování.
4.2.6. Fáze 5: Návrh systému měření výkonnosti Reporty: Report plnění OLA; Náklady na výstupy procesu; Náklady na aktivity procesu Report plnění OLA byl pro první release nového systému řízení poměrně problematický. Důvodem byla neexistence uzavřených OLA. Jako takový byl ale v této fázi stanoven naprosto správně, ovšem k uzavření potřebných dohod v disponibilním čase zkrátka nedošlo a tak poslouţí pro některý z příštích releasů. Další dva reporty jsou označovány jako výkonové a data pro jejich naplnění byla v různé míře detailu z pilotního provozu dostupná.
4.2.7. Fáze 6: Vytvoření řídící dokumentace nového systému řízení V této fázi došlo ke tvorbě a publikování řídící dokumentace všech procesů. Šablona byla pro všechny stejná a jednotliví vlastníci potom postupně vyplňovali konkrétní údaje za svůj proces. Tato dokumentace byla poté zaslána Vedoucímu projektu ke schválení a její legalizaci.
~ 59 ~
4.2.8. Fáze 7: Příprava nasazení nového systému řízení do provozu Po přípravě nové řídící dokumentace došlo k momentu, kdy ji bylo nutné představit výkonným pracovníkům, kteří se jí následně budou řídit. Za tímto účelem, kaţdý vlastník procesu vypracoval prezentaci a sezval pracovníky, plánované do svých rolí, ke školení. Na nich padala směs kuriózních dotazů s ne příliš příznivými ohlasy, a proto bylo velice obtíţné tato školení realizovat. Dalším bodem této fáze byla tvorba plánu implementace procesu. Byl to dokument v Excelu, kde si vlastník stanovil, co všechno je nutné udělat, připravit a zařídit (včetně oněch školení), aby mohl vejít 23. 2. 2009 do pilotního provozu. Pro sedmou etapu byla rovněţ plánována úprava nástrojů. Nástroji se nyní myslí workflow nástroj, který měl podporovat nový způsob řízení. Byl zvolen přístup, kdy byl tento nástroj vyvinut vlastními zdroji jedním z pracovníků jako dočasné řešení. Tímto počinem však došlo ke zdvojení vykazovacích nástrojů, coţ přineslo mírně řečeno chaos pro nezasvěcené pracovníky provozu, kteří však byli cílovou skupinou a nástroje museli kaţdodenně pouţívat. O tomto nešťastném řešení se ještě několikrát zmíním.
~ 60 ~
5. Případová studie – projekt #10 (pilotní provoz) Obsahem této kapitoly bude ukázka práce po datu zahájení pilotního provozu a seznámení s řízením zaměstnanců v rolích procesů. Pro její oddělení jsem se rozhodl z důvodu logického uspořádání. Předchozích sedm fází (včetně nulté) se věnovalo návrhu procesu, kdeţto pilotní provoz je zde chápán jako ostré nasazení procesního řízení v konkrétním IT útvaru. Nejednalo se tedy o výběr vzorku zaměstnanců, kteří by byli řízeni dle nového systému, ale šlo o plošné zavedení pro všechny z ORI. Poznámka: Ačkoliv by podle kapitoly 4.1.6 mělo být fází devět, popis zde končí neboť projekt do deváté fáze (do doby dokončení této diplomové práce) nevstoupil. Devátá fáze se bude zabývat vyhodnocením pilotního provozu, dojde k zahájení zvyšování efektivity a výkonnosti podle Plánu trvalého zlepšování a nakonec v ní bude uskutečněna příprava nových změn pro druhý release R2.
5.1.
Způsob řízení požadavků a zaměstnanců
Osmá fáze – Pilotní provoz začala dle Harmonogramu 23. 2. 2009. Na venek (pro do implementační fáze projektu nezainteresované lidi) se změnilo v podstatě velmi málo35. Tato změna spočívala v přijímání a zadávání poţadavků jiným způsobem, a sice interně naprogramovaným nástrojem pro podporu workflow jednotlivých procesů. Zde je nutné říci, ţe tento nástroj nebyl jediný, neboť do té doby oficiální nástroj pro řízení poţadavků stále zůstává jediným uznávaným kontaktním místem (SPOC – Single Point of Contact) pro celou organizaci. Zde docházelo, a i zhruba po 1 a ½ měsíci dochází k pochopitelným zmatkům v zadávání poţadavků a vykazování na nich odpracovaného času. Důvodem, proč tomu tak je, a proč nebyla workflow rovnou naimplementována do centrálního nástroje zůstává ten, ţe se jedná o komerční SW se standardním cyklem releasů (jeho úprava je tedy časově velmi náročná a drahá) a tudíţ nebylo v tak krátké době moţné promítnout workflow navrţené vlastníky jednotlivých procesů do tohoto nástroje36. V praxi vše funguje tak, ţe zaměstnanci ORI přijímají poţadavky jak z ITG, tak z workflow nástroje a odpracovaný čas musejí vykazovat do kaţdého zvlášť. K ještě více 35
To můţe být můj subjektivní pohled, někdo i dále popsanou změnu vnímal poměrně intenzivně Jedná se o Mercury / HP ITG. Funguje tedy jako centrální HelpDesková aplikace. Tento SW je ovšem primárně určen pro řízení a plánování IT aktivit, takţe je navíc jeho pouţití jako HD aplikace velmi diskutabilní 36
~ 61 ~
schizofrenní situaci dochází při zadávání poţadavků, kdy musejí dle adresáta zvolit příslušný nástroj (pro lidi uvnitř ORI pouţívat WF nástroj, pro ty vně pouţívat ITG). Dalším rozdílem je odpovědnost nadřízenému za zadané úkoly. Původně byl kaţdý zaměstnanec odpovědný pouze svému liniovému nadřízenému, kdeţto v tomto systému je pracovník odpovědný vlastníkovi respektive manaţerovi konkrétního procesu, ke kterému ten který poţadavek náleţí. Tedy to je ideální stav, pokud mám sdělit osobní zkušenost, lidé si to i po té době zcela neuvědomují. Největší problémy jsem však zaznamenal (spíše dříve, ale i nyní se ještě tento fenomén vyskytuje) s vykazováním odpracovaného času pro „můj“ proces. Ten mám nastavený tak, ţe jednou týdně (v pondělí) přijde automaticky správci poţadavek na Provoz, správu a monitoring konkrétního systému / části infrastruktury. Ten by jej měl v pátek či následující pondělí během dne uzavřít s vyplněním, kolik času aktivitami pro Operations a který den věnoval. O navracení takto vyplněných výkazů bych mluvit nechtěl, to se dá zajistit. Problém je, ţe lidé (ač jsou vyškolení) nedokáţou přesně oddělit poţadavek procesu Operations „Provoz… systémů“ od poţadavků z Technical Supportu, Deploymentu a dalších procesů. Stává se tedy, ţe vyplňují 8 hodin denně, i kdyţ čas odpracují nad úkoly řešenými pro jiný proces (na který si také samozřejmě vykáţou odpracovaný čas), takţe tím dochází ke dvojímu započítávání celkové odpracované doby. K zamezení tohoto neduhu pracuji na dokumentu, ve kterém shromaţďuji aktivity, které patří procesu Operations. Toto bude vytvořeno pro kaţdou část infrastruktury ve velké míře podrobnosti a následně publikováno. Je moţné a zatím se mi to jeví jako jediný účinný způsob, ţe budu (budeme) obcházet jednotlivé správce a sledovat jak pracují a vykazují. Poté, je moţné ţe dojde k odhadnutí denní doby strávené pro proces Operations a nebude třeba zatěţovat administrátory vyplňováním výkazů. Toto se bude například dvakrát ročně revidovat (pokud například správci přibudou pod správu další systémy apod.). Z pohledu projektu se pak změnila frekvence konzultací externího školitele s vlastníky procesů. K té, na rozdíl od fází přípravy, nyní dochází 1x za 14 dní. Důvodem je pouze kontrolní a korekční charakter těchto setkání, zatímco dříve šlo nastavování nového systému řízení a frekvence schůzek byla proto dvakrát taková.
~ 62 ~
5.2.
Návrh úprav procesu Operations pro R2
Pro druhý release jsem si stanovil následující cíle: způsob řízení, ověřování a zlepšování kvality výstupů bude navrţen na základní úrovni Tento cíl mi jako jediný zbyl z releasu R1, jelikoţ se na něj z časových důvodů nedostalo a do nasazení R2 jiţ nedostane. Jak jsem uţ jednou zmiňoval, původně ani nebyla kvalita jednotlivých výstupů z procesů ověřována37. To se však záhy objevilo jako nedostatek, protoţe z logiky věci by k tomu docházet mělo. Do této doby byly výstupy kontrolovány vlastníky (manaţery procesů) od oka a spíše subjektivně a nebyl puštěn pouze výstup, který vyloţeně nevyhovoval. Proces Operations to měl (a ještě má) navíc zkomplikováno tím, ţe hlavní výstup – „Stabilní a bezpečná ICT infrastruktura“ nemůţe být přesně kontrolován, protoţe OLA nesoucí konkrétní parametry a měřítka stability infrastruktury dosud nebyla uzavřena. Pro R2 tedy budu spolu se SLM směřovat k jejich uzavření, aby bylo moţno sledovat (dle přesně daných parametrů, které budou jejich součástí) dodrţování kvality onoho nejdůleţitějšího výstupu procesu Operations. Jak monitorovat a zlepšovat kvalitu ostatních výstupů ještě dodatečně navrhnu a prosadím. úprava výstupů tak, aby lépe odráţely poţadavky z R1 Původně jsem si stanovil výstupy hlavně podle ITILu v2 z knihy o Infrastructure Managementu. O úpravě výstupů ještě nejsem plně rozhodnut, ale pokud k ní dojde, půjde o redukci, případně o jejich úpravu. Ta bude odráţet zkušenosti z pilotního provozu38. zpřesnění a postupné plnění obsahu provozní dokumentace Tento výstup je pro mě osobně „noční můrou“. Nikde dosud neexistuje a ani neexistoval nějaký náznak systému v provozní dokumentaci různých částí infrastruktury, která je vskutku rozmanitá a rozsáhlá. O způsob, jakým řešení tohoto problému uchopit, se 37
Mluvím za Operations. Jak tomu bylo v jiných procesech mi není známo, ale já měl vedle výkonových reportů (které sem nelze počítat) stanoven pouze report plnění uzavřených OLA, který by odráţel kvalitu dodávaného výstupu „Stabilní s bezpečná ICT infrastruktura“ 38 Vstupy a výstupy procesů se navrhovaly hned ze začátku projektu. V tu dobu se ještě ani nevědělo, ţe se novými pravidly nebude řídit dispečink IT, správa osobních PC a notebooků, atp., ač jsou to klasičtí adepti procesu Operations
~ 63 ~
pokoušelo uţ mnoho lidí přede mnou a já proto její zajištění a shromáţdění beru jako velkou výzvu. Nebojím se říct, ţe bude tento úkol součástí Plánu trvalého zlepšování ještě pro řadu releasů aktualizace KPI Pravděpodobně téţ upravím KPI rolím následujícím způsobem: o Vlastník procesu (Odejmu, popřípadě upravím KPI „Ekonomické ukazatele v procesu Operations“. Ţádný takovýto ukazatel ještě v této fázi nebyl stanoven a tak je i jeho sledování a tím plnění KPI bezpředmětné). o Manaţer provozu / vedoucí směny (Oba takto39 stanovené ukazatele mají určitě smysl do budoucna, v tuto chvíli jej však postrádají, protoţe není definována dostupnost sluţeb infrastruktury) o Analytik plánování provozu (Dojde k eliminaci stávajících a navrţení nových KPI) o Administrátor (Zde jsem naopak s určenými KPI spokojen a neplánuji jejich úpravu) uzavření OLA Uzavření OLA je dalším cílem pro R2 a myslím ţe v „nějaké“ podobě cílem dosaţitelným. Tyto poţadavky se ozývají i z vedení (nejen projektu) a proto jiţ začínám shromaţďovat materiály k jejich uzavření. Jejich vytvořením budu mít navíc důleţitou metriku a budu moci reportovat to, k čemu jsem se zavázal jiţ při navrhování procesu. Nutnou podmínkou je však funkčnost SLM procesu, která do teď nebyla úplně samozřejmá, ale nově mám signály o jeho nastartování správným směrem. úprava reportů Reporty stanovené ve 4.2.6 budou pravděpodobně upraveny a doplněny. Rovněţ stanovím, po dohodě s projektovým manaţerem, periodicitu jejich dodávky. návrh a vytvoření mechanismu generování sestav provozované infrastruktury
39
Viz 4.2.3, Role: …
~ 64 ~
Protoţe doposud neexistuje mechanismus generování prvků infrastruktury provozované procesem Operations, učiním dohodu s CfM o úpravě CMDB tak, aby se dle určitého příznaku dal tento seznam vytvářet automaticky. Nyní, chci-li potřebné informace získat, jde o ruční zadávání dotazů a následné generování pohledů, které navíc ne vţdy vyhovují mým záměrům. úprava workflow v případě, ţe to budou závěry pilotního provozu vyţadovat (například ladění systému) Úprava workflow je další moţnou změnou pro nadcházející release. Nepůjde o zásadní změny, ale pouze například o vyčlenění tuningu systému, který nyní není explicitně vyjádřen jako samostatný procesní krok workflow. Je rovněţ moţné, ţe krok OPs410 (workflow v 4.2.3) zcela zanikne. Na závěr nelze opomenout uvést zavedení (v případě nákladů na aktivity procesu zpřesnění) výkonových charakteristik pro tento release: nastavení objemu výstupů dle poţadavků nadřízeného „procesu“ ICTIM nastavení nákladů výstupů procesů, případně nákladů aktivit dle poţadavků nadřízeného „procesu“ ICTIM. Všechny dané cíle se pokusím pro R2 naplnit. Není jich zrovna málo a jiţ nyní vidím, ţe některé půjdou i do dalších releasů. Toto se týká především provozní dokumentace, ale je moţné, ţe přibudou další. Vše, co jsem v této podkapitole popsal je jiţ předmětem podaného RfC a pouze čekám na vyjádření projektového manaţera, zda bude návrh změn schválen. Poté se jiţ mohu směle pustit do úpravy procesu Operations.
~ 65 ~
Závěr V závěrečné části bych rád čtenáře seznámil s výsledky mojí práce, po nichţ budou následovat návrhy na to, čeho se příště u podobných projektů vyvarovat nebo co by se dalo v jiţ zaběhnutém provozu ex-post změnit a vylepšit. Budou slovně ohodnocena i rizika (velké, střední, malé), a případné dopady, které můţe neřešení situace s sebou přinést.
Výsledky Kapitola 5.2 uţ vlastně naznačila moţné výsledky pilotního provozu pro proces Operations. Snaţila se říci, které části mého procesu jsem v pilotním provozu identifikoval jako nedostatečné či nevyhovující a byly tam publikovány navrhované změny pro další release.
Výhrada první (vlastnictví procesů) První netriviální výhrada, kterou na tomto místě musím uvést, se týká (ne)jmenování zástupců vlastníků procesů. Konkrétně jde o to, ţe tři ze sedmi vlastníků neměli stanovené své zástupce. I z vlastní zkušenosti musím říct, ţe o ně opakované ţádali, ale vţdy se to odloţilo na neurčito a tento stav nadále trvá. Dopad například odchodu vlastníka procesu ze společnosti má za následek, ţe není nikdo kompetentní, kdo by jeho agendu převzal. Slovo kompetentní je zde velice důleţité neboť věc, na které vlastník pracuje půl roku a je na svůj proces téměř permanentně školen, se nedá pro nezasvěceného člověka v rozumné době a s přiměřenými náklady pojmout. Toto se v našem případě týkalo procesů CaM, Operations a SRM. Řešení je zde nasnadě – promptní jmenování zástupce/ů vlastníků. Riziko neúspěchu (při nedodržení daných návrhů) pro proces: velké! Nevhodně zvolení vlastníci a / nebo jejich časté střídání. Časté střídání či nevhodně zvolení vlastníci (nezájem, téměř donucení k výkonu role) rovněţ pozitivně nepřispívají dobře navrţeným procesům. Zde ale můţe riziko variovat a být dokonce sníţeno na minimum, pokud odvolaní vlastníci či ti, kteří se funkce zbavují, své nástupce pomohou dobře vyškolit a v začátcích jim pomáhat. Riziko neúspěchu (při nedodržení daných návrhů) pro proces: malé aţ střední! ~ 66 ~
Výhrada druhá (příprava projektu) V teoretické části bylo zmíněno, ţe není dobré oddělovat řízení sluţeb (ITSM) a řízení infrastruktury (ICTIM). Na tuto skutečnost naráţím z toho důvodu, ţe program SIP 1-9 odstartoval bez návrhu procesů Infrastructure Managementu. Jejich souběh by jistě pomohl k lepšímu nastavení rozhraní všech procesů, tedy lepšímu toku vstupů, výstupů a všeobecně informací mezi procesy v rámci ITSM a ICTIM. Při návrhu ITSM procesů došlo totiţ ke zformování Service Desku (SD)40 a nemalá část zaměstnanců do něj byla, z původních pozic v ORI, obsazena. Ovšem v průběhu Projektu č. 10 se posléze ukázalo, ţe chybějí zaměstnanci rutinního provozu (Operations) a nastala tendence k převedení části zaměstnanců ze SD zpět do ORI. Zde je návrh jednoznačný. Takovýto velký projekt respektive program SIP 1-9,10 musí být předem dobře naplánován se zváţením všech moţných důsledků a omezení. To si zajisté ţádá zkušený projektový management. Riziko neúspěchu (při nedodržení daných návrhů) pro celý program: střední aţ velké!
Výhrada třetí (více než jeden vykazovací systém) Pro důvody nastíněné v kapitole 5.1 existovaly pro odbor ORI dva respektive tři vykazovací (a činnosti evidující) nástroje. Toto jsem od samého začátku nejenom já vnímal jako problém a do té doby ne zcela kladné ohlasy zaměstnanců to ještě zesílilo. Kdyţ odhlédneme od faktu, ţe měli problém s chápáním co a kam vykazovat, skutečnost ţe musí pokaţdé otevírat jiný nástroj a potýkat se, se zcela odlišným rozhraním není jistě příjemná! Původně dva nástroje (ITG a pro Projekt č. 10 naprogramovaný workflow nástroj) doplnil ještě třetí – MS SharePoint, kvůli jednomu vedoucímu referátu a vlastníkovi Technical Support v jedné osobě, který si jej oblíbil. Návrhem na zlepšení stavu je pak redukce počtu na jediný vykazovací nástroj (kdybych se chtěl pouštět do úvah, které k tématu nepatří – tím nástrojem by nebyl ani jeden ze tří současných). Riziko špatného vnímání nového systému řízení a případné bouření zaměstnanců (při nedodržení daných návrhů): velké!
40
V literatuře nebývá povaţován za proces, ale za funkci
~ 67 ~
Výhrada čtvrtá (organizační struktura versus procesní řízení) „Zlaté“ pravidlo procesního řízení říká, ţe by organizační struktura neměla překáţet procesům. Dále, a to s tím souvisí, ţe by procesy neměly být „nakresleny“ podle organizační struktury. Tento přístup byl ale hned od počátku porušen! Do infrastruktury, předmětu Projektu č. 10, naprosto logicky patří správa sálů (UPS, klimatizace, prvky fyzického zabezpečení), správa výpočetní techniky koncových uţivatelů, tiskáren a gró procesu Operations – centrální monitoring, dispečink IT. Tyto dvě oblasti však dle původní organizační struktury nenáleţí pod odbor ORI a tak, a to je podle mého zásadní chyba, nejsou součástí projektu a nejsou tedy řízeny procesně. Můj zásadní nesouhlas s tímto stavem trochu zmírnil jeden z plánů do budoucna, který počítá se zavedením nového referátu, kde by snad měli být lidé provozující i prvky infrastruktury, které do ní mají patřit (opět ale bez správy koncových stanic). Výše uvedené neznamená, ţe by naopak měla být organizační struktura hned předělána podle navrţených procesů. Jen si obě tyto nesmí překáţet, ale znovu připomínám, nikdy by se procesy neměly malovat podle organizačních struktur. Následující dva obrázky potom ukazují stav současný (Obrázek 9) a stav ţádoucí (Obrázek 10). Riziko absence synergického efektu, který by vznikl dodržením daných doporučení: velké! Obrázek 9 „Současný stav procesního řízení ICT Infrastruktury“ Odbor bezpečnosti IT
Náměstek GŘ pro IT
Odbor controllingu IT
Odbor provozní podpory NŽP
Odbor provozu systémů
Úsek IT Governance
Úsek provozu IT
Odbor rozvoje infrastruktury
Odbor podpory uživatelů IT
Odbor SD
Odbor architektury ICTIM procesy
Odbor řízení kvality služeb
Zdroj: autor
~ 68 ~
Úsek vývoje IT
Odbor vývoje systému X
Odbor řízení projektů
Odbor vývoje systému Y
Odbor péče o interní klienty
Obrázek 10 „Budoucí, navrhovaný stav pokrytí procesy ICTIM“ Odbor bezpečnosti IT
Náměstek GŘ pro IT
Odbor controllingu IT
Odbor provozní podpory NŽP
Odbor provozu systémů
Úsek IT Governance
Úsek provozu IT
Odbor rozvoje infrastruktury
Odbor podpory uživatelů IT
Odbor SD
Odbor architektury ICTIM procesy
Odbor řízení kvality služeb
Úsek vývoje IT
Odbor vývoje systému X
Odbor řízení projektů
Odbor vývoje systému Y
Odbor péče o interní klienty
Zdroj: autor
Slovo závěrem Při návrhu procesního řízení ve společnosti, kde nikdy předtím nebylo, je situace vţdy o něco obtíţnější neţli tam, kde v podvědomí pracovníků tento způsob práce jiţ delší dobu tkví. Po navrţení procesů nejde pouze o moţnou změnu organizační struktury, ale především o změnu myšlení lidí! Bez této změny mohou vlastníci navrţených procesů a s nimi celý management zapomenout na efektivity plynoucí ze zavedení procesního řízení v podniku. Další nutnou podmínkou nastartování a prosazování procesního přístupu je reálný zájem vedení společnosti. Zdá se to jako jasná věc, ale zdaleka tomu tak v praxi není. Opět zde mohu dát jako příklad mé současné zaměstnání. Těsně před uzavřením této práce bylo ohlášeno, ţe se bude měnit organizační uspořádání současných IT útvarů s podstatnými personálními dopady i do výše popisovaného projektu (o projektu samotném nic nezaznělo). Projekt jako takový za pár dní končí, ale osud jeho výsledků, jimiţ jsou mimo jiné nastavené procesy pro řízení infrastruktury, je zatím neznámý. Nezbývá tedy neţ doufat, ţe velký kus odvedené práce a značné finanční prostředky nepřijdou vniveč a nově vzniknuvší (rozšířený) referát z výše popisovaného odboru převezme výsledky půlročního úsilí mnoha lidí. ~ 69 ~
Pro úplnost ještě dluţím zmínku o projektech 1 – 9 programu SIP. Některé jeho procesy (respektive funkce SD) přešly do linie, některé si vzal později za své projekt č. 10. Mám-li říci své subjektivní hodnocení a hlasy lidí blízko těmto aktivitám musím konstatovat, ţe nebyl příliš úspěšný, ač oficiální proklamace znějí jinak. Ať je to tak jak si myslím já, nebo úplně jinak, společnost ve které pracuji se před necelým rokem (u některých procesů jiţ podstatně dříve) vydala na nelehkou cestu k přerodu zastaralého funkčního stylu řízení k řízení procesnímu a učinila tak v kaţdém případě krok správným směrem a já doufám, ţe v dohledné době dojde k ustálení turbulentních změn ve všech jejích útvarech a přerodu na moderně řízenou organizaci 21. století.
~ 70 ~
Seznam použitých zdrojů 1. Truneček, J. a kol.: Management v informační společnosti. Ediční oddělení VŠE Praha 1997 2. Úvodní přehled ITIL, itSMF 3. OGC: ICT Infrastructure Management, 2002 4. BPM
téma,
O
vlastnictví
procesů,
dostupné
z WWW:
http://bpm-
tema.blogspot.com/2007/04/vlastnci-proces.html 5. ITIL.cz portál. O ITILu, popis IT Service Managementu, dostupné z WWW: http://www.itil.cz/index.php?id=982 6. ITIL.cz portál. O ITILu, popis IT Service Managementu, dostupné z WWW: http://www.itil.cz/index.php?id=914 7. BPM Portál, pojednání o organizačních strukturách a procesech, dostupné z WWW: http://www.procesy.cz/temata/Organizacni-struktury-a-procesy.htm 8. ITSM portál itsm.sk, vztahy ITIL s normami kvality a Cobit, SixSigma aj., dostupné z WWW: http://www.itsm.sk/sk/ITIL/Co-je-to-ITIL.alej 9. ITSM IT – Service Management Software dostupné z WWW: http://www.ietsolutions.com/desktopdefault.aspx/tabid-4/9_read-4/ 10. Projektová dokumentace ČP 11. Materiály firmy Win4all 12. Úvodní přehled ITIL v3, itSMF
~ 71 ~
Přílohy
~ 72 ~
