Využití ITIL Change Management procesu k implementaci změn v datovém centru

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Využití ITIL Change Management procesu k implementaci změn v datovém centru

Diplomová práce

Autor:

Bc. Bohuslav Radomír Informační technologie, Manažer projektů IS

Vedoucí práce:

Praha

Ing. Václav Šebek, CSc.

duben, 2010

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne: ...................................

......................................... Radomír Bohuslav

Poděkování Touto cestou bych rád poděkoval své přítelkyni a synovi, kteří mě po celou dobu mého studia podporovali a poskytovali mi potřebný prostor. Dále bych rád poděkoval kolegovi RNDr. Zdeňku Suchelovi, který mi svými zkušenostmi a svým precizním přístupem pomohl vytříbit mé vlastní názory, které dále formovaly tuto práci. A v neposlední řadě také vedoucímu mojí práce panu Ing. Václavovi Šebkovi za jeho pomoc při dalším formování této práce a poskytnuté konzultace.

Anotace práce Cílem této práce je popsat implementaci jednoho z ITIL procesů na příkladu konkrétního podniku a současně se zaměřit na problémy a výzvy, které se mohou vyskytnout při implementaci procesu a výběru vhodného nástroje pro jeho podporu. Práce je tvořena dvěma teoretickými kapitolami, které čtenáři v úvodu osvěží pojem procesního řízení a jeho rozdílů oproti řízení funkčnímu. Obsahem této kapitoly je i procesní charakteristika popisované organizace. Následující teoretická část popisuje celý ITIL rámec, jeho složení, účel a charakteristické prvky. Celou teoretickou část zakončuje popis Change Management (CM) disciplíny, jak ji definuje zmíněný ITIL. Praktickou část práce tvoří tři kapitoly. Prví seznámí čtenáře s konkrétní implementací CM procesu v datovém centru. Tato část si kromě samotného popisu procesu klade za cíl popsat zmíněný proces tak, jak v praxi opravdu funguje, a to na příkladech včetně jeho předností a nedostatků, které umožní čtenáři lepší orientaci v dané problematice. V navazující kapitole je kromě blíže rozepsaných předností a nedostatků, diskutována odchylka popsané praktické implementace a teoretické definice. Celou práci zakončuje přehled hlavních nástrojů, které jsou pro CM stěžejní, a navrhuje směr jejich budoucího vývoje.

Abstract Main aim of this thesis is to describe implementation of one of the ITIL process on one particular company example together with all issues and challenges that can arise. First part of this thesis contains two theoretic chapters. First is describing and comparing process and function driven organizations together with company description. Second chapter describes whole ITIL framework and Change management discipline. Practical part of the thesis is separated into three chapters. First is describing Change management implementation in concrete datacenter with preferences, disadvantages and examples for better understanding. Following chapter is comparing the implementation according to ITIL definition and elaborating mentioned preferences and deficiencies. Final chapter is describing main tools that are for the Change management mandatory with focus on the direction of the future development.

Obsah 1

Procesně řízený podnik ............................................................................................... 8

1.1 Funkční organizace................................................................................................ 8 1.2 Procesní organizace ............................................................................................... 9 1.3 Procesní struktura DHL IT Services.................................................................... 10 2 Change management dle ITIL ................................................................................. 13 2.1 Information Technology Infrastructure Library (ITIL) ....................................... 13 2.2 Information Technology Infrastructure Library V2 ............................................ 15 2.1.2 Dodávka služeb (Service Delivery) ............................................................. 16 2.1.3 Podpora služeb (Service Support)................................................................ 17 2.3 Od ITIL k ITIL V3 .............................................................................................. 19 2.4 ITIL Change management ................................................................................... 22 2.4.1 Oblasti aplikace ........................................................................................... 23 2.4.2 Příčiny vzniku Změn ................................................................................... 24 2.4.3 Change management a okolní procesy ........................................................ 24 2.4.4 Druhy a klíčové elementy RFC ................................................................... 25 2.4.5 Change management proces dle ITIL.......................................................... 26 3 Change management v datovém centru .................................................................. 32 3.1 Základní Change management proces................................................................. 32 3.2 Change initiation ................................................................................................. 34 3.2.1 Kategorizace změn podle rozsahu ............................................................... 38 3.2.2 Kategorizace Změn podle úrovně rizika...................................................... 39 3.2.3 Kategorizace změn podle jejich priority...................................................... 41 3.2.4 Workflow a rozdělení zodpovědností.......................................................... 42 3.3 Change Impact Analysis & Risk ......................................................................... 44 3.3.1 Workflow a rozdělení zodpovědností.......................................................... 47 3.4 Change Review & Approval................................................................................ 48 3.4.1 Workflow a rozdělení zodpovědností.......................................................... 51 3.5 Create Change Package ....................................................................................... 52 3.5.1 Rozdělení zodpovědností............................................................................. 53 3.5.2 Change package........................................................................................... 54 3.5.3 Workflow a rozdělení zodpovědností.......................................................... 61 3.6 Implement Change............................................................................................... 63 3.6.1 Workflow a rozdělení zodpovědností.......................................................... 64 3.7 Review Change and Close................................................................................... 65 3.7.1 Workflow a rozdělení zodpovědností.......................................................... 66 3.8 Týdenní cyklus zpracování Změn........................................................................ 66 3.9 Urgent a Emergency proces................................................................................. 68 4 Nedostatky implementace ......................................................................................... 71 4.1 Co je implementováno podle ITIL ...................................................................... 71 4.2 Týdenní zpracování Změn ................................................................................... 74 4.3 Emergency Restoration Report............................................................................ 75 4.4 Pozdě příchozí Změny ......................................................................................... 77 4.5 Change management proces vs. zákazník ........................................................... 79 5 Nástroje pro implementaci ....................................................................................... 81 5.1

Nástroj HPSD ...................................................................................................... 81

5

Specifikace požadavků na nový systém ...................................................................... 81 Migrace HPSD na Service Manager............................................................................ 82 5.2 Nástroj IQG manager........................................................................................... 83 Budoucnost IQG4You ................................................................................................. 84 5.3 Online SBF .......................................................................................................... 85 Propojení SBF a CMDB .............................................................................................. 86 Závěr ................................................................................................................................... 87 Seznamy použitých zdrojů................................................................................................ 89 Seznam zkratek.................................................................................................................. 90 Slovík důležitých pojmů.................................................................................................... 91 Seznam obrázků................................................................................................................. 93 Seznam tabulek .................................................................................................................. 94 Seznam grafů ..................................................................................................................... 94 Přílohy ................................................................................................................................ 95

6

Úvod Informační Technologie (IT) jsou již mnoho let nedílnou součástí našich životů, ať si to více či méně uvědomujeme. V mnohých oblastech nám podstatně ulehčují práci nebo ji za nás přímo vykonávají. Rovněž nám pomáhají zorientovat se v dnešní záplavě informací, kterou bohužel samy i částečně vytvářejí nebo pomáhají vytvářet. S postupným nárůstem počtu podnikových IT služeb a jejich důležitosti pro samotný byznys se začaly zvyšovat i nároky na jejich kvalitu (rychlost, dostupnost a bezpečnost) a v neposlední řadě se také objevily snahy o snižování provozních IT nákladů. Tyto požadavky se tak staly hlavním motivem snahy o maximální centralizaci IT systémů. Díky tomu vznikla datová centra (DC), která se tak v dnešní době stala jednou z nejdůležitějších součástí informačních systémů. Proto aby DC splnila dané požadavky, musí poskytovat stabilní technické zázemí, což v sobě většinou obnáší: zálohované zdroje elektrické energie (UPS, generátory), zálohované zdroje chladu (klimatizace), zálohovanou síťovou infrastrukturu (duální síťové cesty), protipožární opatření (zhášecí plyn) a řízení na monitorování přístupu k serverům (zajištění bezpečnosti). Kvalita zmíněných vybavení v různých DC se přitom může lišit. To vychází z faktu, že ne vždy je možné si dovolit to nevyšší možné zabezpečení/dostupnost služby, jelikož je vhledem k potřebnému technickému zázemí drahé. Je třeba si však uvědomit, že pouze technické zajištění není v této situaci plně dostačující. DC je složitý systém propletených a provázaných služeb (aplikací). A to jak na úrovni aplikační (využívá/poskytuje prostředky jiné aplikaci), tak i na hardwarové úrovni (sdílení stejného HW prostředí). Změna v určité aplikaci nebo na úrovni systému (např. změna formátu vyměňovaných aplikačních dat, změna knihoven či dalších komponent systému) může vyvolat chybu aplikace a následnou nedostupnost služby, přestože z technického pohledu DC je vše ostatní v pořádku. Tato diplomová práce v následujících kapitolách popíše jeden ze způsobů, jak se s problémem častých změn na všech úrovních DC v praxi velmi efektivně vypořádat a mít je neustále pod kontrolou. Jelikož se jedná o IT tématiku, je doslovný překlad všech anglických výrazů poměrně diskutabilní a v některých případech, vzhledem k zažitému anglickému výrazu, nevhodný. Z tohoto důvodu autor ponechává některé výrazy v angličtině (v textu jsou vyznačeny kurzívou), jsou však doplněny českou koncovkou. Z toho důvodu je přílohou této práce významový slovník.

7

1 Procesně řízený podnik Procesní řízení je pojem, který je v dnešní době, často označované jako informační, již velmi dobře znám a široce využíván. Obecně se dá říci, že procesní řízení se stalo standardem neustálého vývoje a optimalizace firmy, nutným k udržení kroku s konkurencí nebo v lepších případech nástrojem umožňujícím získání jisté konkurenční výhody. Procesně řízený podnik si totiž klade za svůj hlavní cíl spokojenost zákazníka (ať už interního nebo externího), jenž na výstupu procesu obdrží či nakupuje službu nebo produkt. Tímto pojetím se procesní přístup zásadně odlišuje od předchozího funkčního přístupu, který byl zaměřen jen na poměrně „slepé“ vytvoření určitého výstupu – vykonání dané funkce či úkolu. Pojetí či definic procesního řízení je dnes celá řada, itil.cz definuje několik příkladů takto1:
procesní řízení je filozofie řízení, která hájí integrované pojetí řízení procesu od počátku do konce, včetně elementárních činností, v nichž vzniká produkt nebo služba pro daného zákazníka,
procesní řízení je vyhodnocení a v případě potřeby restrukturalizace funkcí systému s cílem zajistit co nejefektivnější a nejhospodárnější provádění procesu,
pojem procesní řízení označuje sled činností, které organizace provádí buď za účelem optimalizace svých klíčových procesů nebo je přizpůsobuje svým novým potřebám.

1.1 Funkční organizace Funkční řízení organizace je předchůdcem procesního řízení. Z tohoto důvodu jej autor krátce popíše, aby lépe vynikl rozdíl a vývoj, které procesní řízení přináší. Funkční způsob řízení je specifický tím, že složitější úkoly či práce jsou rozděleny na jednodušší části, které tak může provádět i méně kvalifikovaný pracovník. Toto dělení práce zároveň vytváří funkční jednotky/útvary, organizované na základě odbornosti. Vlastní organizační struktura je složena z těchto útvarů, jež vykonávají dílčí činnosti nějakého procesu (projektu, akce, úkolu), aniž by byl sledován celý tok činností jako celku. Pracovníci provádějící jednotlivé činnosti neznají okolní návaznosti, proto jsou přechody mezi jednotlivými útvary prostorem pro chyby a zpomalují celý proces. Pro koordinaci 1

Zdroj http://www.itil.cz/index.php?id=914

8

jednotlivých útvarů je potřeba kontrolních pracovníků, kteří však nepřidávající žádnou hodnotu na výstupu, ba naopak, mohou bránit novým změnám, aby si zachovali svou funkční pozici. Organizační struktura je pyramidová s omezenou možností delegování odpovědností, jelikož je řízena centrálně. Díky tomu je rovněž veliká pravděpodobnost duplikování aktivit na druhém produkčním konci pyramidy.

Nevýhody

Výhody

Tabulka 1. Výhody a nevýhody procesního řízení 

Jednoznačné zaměření na odbornost/kvalifikaci pracovníků



Jednoduché vytváření oddělení nebo skupin lidí (se stejnou profesí nebo dle určité příslušnosti v části organizačního řetězce)



Zaměření na měření dílčí efektivnosti – tato hodnota vypovídá jen o schopnostech části organizační jednotky/řetězce (scale efficiencies)



Relativně jednoduché měřit – měření výstupu části organizační jednoty/řetězce



Relativně jednoduché pochopit strukturu organizace



Ztrácí se přehled nad kompletním řetězcem činností



Existuje možnost, že funkční jednotka bude prosazovat své zájmy, které budou negativně ovlivňovat pružnost celého řetězce – jako např. následné snížení efektivity či rychlosti odezvy apod.



Obtížná implementace nových či změněných procesů – oddělení sledují pouze své zájmy, různě veliká rezistence oddělení měnit cokoliv již zaběhnutého



Obtížná identifikace viníka, oddělení svalují vinu jedno na druhé, přičemž chyba může být na obou stranách. Chybí zodpovědná osoba, koordinátor Zdroj: Vlastní tvorba

1.2 Procesní organizace Procesní organizace má kromě svého hlavního zaměření na zákazníka a jeho potřeby i další specifika, kterým se bude věnovat tato kapitola. Procesní řízení organizace umožňuje daleko pružnější reakci na požadavky zákazníka. To lze popsat i jako neustále se rozvíjející a zlepšující se schopnost vytvářet rozmanité produkty (výstupy) efektivně, účelně a hospodárně. A to proto, že podstatu procesního řízení definuje jeho cíl. Procesní organizace je systémem vzájemně provázaných procesů1. Aby bylo možné zmíněného cíle dosáhnout, je třeba splnit tyto základní podmínky2:
pracovní postup/proces je definovaný a ucelený sled činností napříč organizací,

1

Norma ČSN EN ISO 9000, 2001 charakterizuje procesní přístup ve vztahu k výsledku takto: „Požadovaného výsledku dosáhneme mnohem účinněji, jsou-li činnosti a související zdroje řízeny jako proces” 2 Tyto podmínky definují ideální stav, ke kterému vede dlouhá a strastiplná cesta, kterou lze velmi dobře popsat pomocí CMMI modelu. Více viz. http://cs.wikipedia.org/wiki/CMMI

9


jsou definovány osobní zodpovědnosti za samotný proces (vlastník procesu), ale i za každou činnost,
pro každý proces jsou definovány jeho vstupy, výstupy a potřebné zdroje,
je nastaven systém měření výkonnosti procesů - každý proces je sledován a vyhodnocován,
optimální využívání zdrojů a průběžné zvyšování výkonnosti organizace dle předem stanovených měrných ukazatelů spolu s dodržováním stanovené kvality výstupů,
procesní přístupu je trvale podporován ze strany vrcholového managementu organizace. Procesní organizace si musí být vědoma svých procesů, jejich vstupů a výstupů, způsobu, jakým se tyto vstupy mění na výstupy, a musí vědět, jaké zdroje se přitom spotřebovávají. Zároveň musí být neustále prověřovány všechny činnosti, dle stanovených výkonnostních charakteristik a parametrů, které jsou nutné pro přeměnu vstupů na výstupy. Zmíněné sledování a vyhodnocování slouží nejen k dodržení stanovené kvality, ale také k neustálému zlepšování procesů. Jednotliví vlastnící procesů jsou odpovědni za sledování těchto charakteristik a navrhují a provádějí změny v procesech, čímž jej optimalizují.

Výhody

Tabulka 2. Výhody a nevýhody procesního řízení    

Nevýhody

    

Zaměření na celý proces od začátku až do konce (end-to-end) Proces roste a zlepšuje se spolu s poznáním celého řetězce činností Na proces se nahlíží z různých úhlů pohledu (outside-in thinking) což napomáhá udržení maximální pozornosti na zákazníka a jeho zájmy Díky popisu procesu je jednodušší změna jeho částí popřípadě změna celého procesu Díky popsanému procesu je podstatně jednodušší zastupitelnost v rámci oddělení. Předávaní práce (hand over) je výrazně redukováno nebo není vůbec třeba. Může dojít k fragmentaci znalostí a schopností Proces se stane velmi komplexním Ztráta kontroly a vyvážení procesu – část procesu se díky ztrátě kontroly nad procesem stane slabým článkem Může docházet k duplicitním aktivitám v rámci dalších procesů Zdroj: Vlastní tvorba

1.3 Procesní struktura DHL IT Services Firma DHL ITS je procesní organizací přičemž procesní řízení jí umožňuje vůbec fungovat. Noví zaměstnanci, kteří nemají zkušenost s procesním řízením, často kritizují samotné procesy, zejména byrokracii s nimi spojenou. 10

To je největší nepřítel procesních organizací, kterého je nutné si pečlivě hlídat a korigovat. Na druhou stranu by ale poskytování dané úrovně kvality služeb bez procesního řízení bylo prakticky nemožné. Následující Obr. 1. přehledně shrnuje hierarchickou strukturu jednotlivých komponent, ze kterých se procesní řízení organizace DHL ITS skládá a které využívá. Pomyslný střed tohoto modelu tvoří pyramidová struktura, na jejímž vrcholu jsou metody(principy) stanovené Senior managementem, které organizace dále využívá pro vytváření a ovlivňování všech rozhodnutí. Poté následují procesy využívané IT celosvětově pro vývoj, nasazení a dodávky IT služeb byznysu. Střed tvoří procedury, jež specifikují, jak jsou procesy prováděny – jejich work flow. Tyto procedury doplňují pracovní instrukce či návody, poskytující detailní popis konkrétních aktivit. Celá pyramida je postavena na podpůrných materiálech definujících např. standardy, návody, šablony a kontrolní seznamy. Tato struktura je obalena/využívá metodiku ITIL, model CMMI, standardy ISO 200001 a projektovou metodologii PRINCE22. Obrázek 1. Jednotlivé komponenty procesní organizace DHL ITS

Zdroj: Interní materiály společnosti DHL ITS

Vraťme se ale k samotným procesům a jejich struktuře. Zralost resp. úroveň procesů používaných ve firmě DHL IS dosáhla na konci roku 2008 CMMI3 úrovně 4. 1

První mezinárodní standard IT Service managementu. Více viz. http://en.wikipedia.org/wiki/ISO/IEC_20000 Více viz. http://www.prince2.com/what-is-prince2.asp 3 CMMI - Capability Maturity Model Integration. Volně přeloženo jako Stupňovitý model dospělosti. Definuje pět stupňů zralosti: Počáteční (Initial), Řízená (Managed), Definovaná (Defined), Měřitelně řízený proces (Quantitatively Managed), Optimalizující (Optimizing). Více viz. http://www.sei.cmu.edu/cmmi/ 2

11

Procesy splňují podmínky definované v předchozím stupni (3) a zároveň je pro jejich kontrolu využíváno kvantitativních analytických technik. Pro měření kvality procesů a subprocesů jsou definovány měřitelné cíle, které jsou zároveň používány k řízení výkonu procesu nebo obecněji řečeno pro rozhodování organizace. Oproti předchozímu třetímu stupni zralosti je organizace schopna předpovídat výkonnost procesu.

Obrázek 2. Struktura procesů ve firmě DHL na nejvyšší úrovni

Zdroj: Interní materiály společnosti DHL ITS

Tato diplomová práce je zaměřena na Change management proces, jenž společně s dalšími procesy Request Managementu a Configuration Managementu spadá do části Service Control Managementu1 vyznačeného na Obr. 2. Change management a Configuration management jsou popsány v následující části věnované ITIL. Request Management je proces poskytující prostředky využívané při vytváření a třídění požadavků na Změnu2 (RFC, Change Request) nebo na Informaci (Request for Information) popř. zajišťuje provedení určité aktivity (např. nákup IT infrastruktury). Tento proces má mnoho vstupů, jelikož požadavků může být celá řada, počínaje požadavkem na Změnu až po Incident konče.

1 2

Detailnější struktura Service Control Managementu je součástí přílohy (1) Změna – předmět Change managementu je dále v označována velkým počátečním písmene.

12

2 Change management dle ITIL Change management je jednou z mnoha částí tvořící rámec Service delivery, který spadá do rodiny publikací ITIL. Tato velmi stručná, ale i výstižná formulace poskytne autorovi v opačném pořadí kostru, dle které budou zmíněné pojmy postupně popsány. V úvodu to bude popis samotné ITIL knihovny, minimum z její historie, důvody jejího vzniku a v neposlední řadě k čemu a proč je ITIL tak dobrý. V další části budou popsány a charakterizovány jednotlivé prvky ITIL knihovny, jelikož se jedná o velmi komplexní a provázaný celek. Na tuto charakteristiku bude navazovat detailnější popis Change managementu a jeho jednotlivých částí. V závěru této kapitoly bude popsána nová verze ITIL V3, která přináší zásadní změnu konceptu a zavádí koncepci, která procesně pokrývá celý životní cyklus služby.

2.1

Information Technology Infrastructure Library (ITIL)

ITIL existuje jako zmíněný soubor poměrně velikého počtu knižních publikací. Popisuje jednotlivé aspekty a způsoby řízení služeb informačních a komunikačních technologií (ICT1), ICT infrastruktury a řízení služeb IT (ITSM2). Pod tímto oficiálním a na první pohled nepřehledným výčtem se skrývá řízení služeb, které IT poskytuje interním nebo externím zákazníkům a samotné řízení IT infrastruktury, na kterém je poskytování zákaznických služeb postaveno. ITIL v tomto kontextu klade důraz hlavně na stabilitu, kvalitu a spolehlivost poskytovaných služeb. ITIL začal vznikat ve Velké Británii v 80. letech minulého století jako vládní zakázka pro vytvoření metodiky řízení IT služeb. Za dobu své existence urazil poměrně dlouhou cestu neustálého vývoje, vylepšování a hledání toho nejlepšího. Od prvotních ITIL verzí, které byly velmi rozsáhlé a byrokratické, se ITIL stále zeštíhluje a zjednodušuje. Obsahem ITIL je soubor pravidel nezávislých na daném typu organizace, systematicky popisující procedury pro zavedení, provozování a řízení IT a IT služeb. Princip ITILu je založen na Best practice přístupu. Best practice představuje použití toho nejlepšího, co se již v dané oblasti osvědčilo jinde. Tyto základy jsou postaveny na zkušenostech více než jedné osoby z více než jedné organizace, s použitím více než jedné technologie a na základě většího počtu událostí. Tento přístup se dá velmi jednoduše 1 2

ICT - Information and Communication Technology ITSM - Information Technology Service Management

13

popsat jako: Proč pracně vymýšlet „něco“, když máme možnost se inspirovat jinde, kde navíc to „něco“ dělají/funguje opravdu dobře. Tento způsob poskytuje velmi dobrou startovní pozici založenou na profesionálním přístupu. Best practice je však jen jednou z mnoha silných zbraní ITILu. Mezi další silné zbraně patří: •

Flexibilita - ITIL lze totiž aplikovat na různě veliké firmy od malých a středních až po globální mezinárodní organizace. Rovněž není vázán žádnou konkrétní platformou,

•

Škálovatelnost – lze implementovat i jen časti procesů dle požadavků a prostředí konkrétní firmy,

•

Dostupnost – používání či implementace ITILu je zdarma. Placené jsou pouze informační zdroje,

•

Měřitelnost, ovladatelnost, proaktivní přístup.

ITIL byl, je a bude dále vyvíjen mnohými experty, odborníky1 z oboru IT. To je nezbytné pro udržení principu best practice a zachování velmi těsného kontaktu s okolní IT realitou. Celá knihovna ITIL je dnes spravována Office of Government Commerce2, která také vlastní ochrannou registrační známku ITIL™. ITIL je šířen formou školení, manuálů, CD a dalších placených materiálů. ITIL také ve značné míře pronikl do v dnešní době perspektivní oblasti vývoje softwarových nástrojů. V návaznosti na zmíněné silné stránky ITILu a best practice je nutné zmínit další zásadní přístup, který ITIL prosazuje. Tímto přístupem je adopt and adapt – převzít a přizpůsobit. V praxi to znamená, že se při implementaci ITSM procesů nejdříve naimplementují pouze základní principy, koncepce či návody, které jsou následně dále rozšířeny dle velikosti, požadavků a charakteru firmy. ITIL tedy nenabízí konkrétní ani univerzální řešení na vše, nýbrž díky právě zaměření na best practice stanovuje “jen” správný směr a říká, čeho je třeba dosáhnout. Tato vlastnost je však na druhou stranu i kritizována. A to tím způsobem, že je ITIL nekonkrétní a není jasně definováno, co přesně se má v určité situaci dělat. Tato vlastnost je ale hlavní postatou ITILu. Každá organizace je svým způsobem unikátní – svým prostředím, zvyky, procesy, firemní kulturou, a proto je nutné konkrétní řešení přizpůsobit konkrétním potřebám.

1 2

Zásadní podíl na rozvoji ITILu má nezisková organizace itSMF – Česká odnož http://www.itsmf.cz/ http://www.ogc.gov.uk/guidance_itil.asp

14

Aplikace jednotného pohledu a konkrétních metod by byla velmi svazující a nevhodná. Organizaci, potažmo prostředí organizace, je potřeba pochopit. Následně pak navrhnout a vyjednat optimální řešení. Tři úrovně řízení procesů dle ITIL1: Strategická úroveň - Řízení IT služeb. Obsahuje řízení kvality, bezpečnost, organizační řízení apod. Taktická úroveň (Service Delivery) - plánování a kontrola IT služeb zajišťující splnění požadavků zákazníka. Operační úroveň (Service Support) - podpora IT služeb zajišťující efektivní poskytování IT služeb ze strany servisní organizace.

2.2

Information Technology Infrastructure Library V2

ITIL V2 byl oficiálně představen v roce 2000. Pro tuto verzi je charakteristický způsob, jakým byla vyvíjena. Autorem je totiž převážně celosvětová rychle se rozvíjející IT Service Management komunita uživatelů (itSMF), která vnikla krátce po vzniku ITIL V1. ITIL V2 se od svého předchůdce odlišuje především tím, že zdůrazňuje potřebu bližšího vztahu mezi samotným zákazníkem a dodavatelem služby. Proto se snaží aplikovat více servisně orientovaný přístup. Vlastní jádro ITIL V2 se dá označit jako opravdu procesně orientované, nicméně však stále vychází z interního IT pohledu. ITIL V2 rovněž obsahuje best practice návody, jak ITIL používat a implementovat. Obr. 3. názorně zobrazuje vztahy procesních modulů – zmíněných ITIL publikací. Celkové prostředí je zde vymezeno fialovými oblastmi, kde business (byznys) procesy jsou na straně jedné a ICT Infrastruktura na straně druhé. Na Obr 3. jsou také vidět velmi těsné vazby The Business Perspective (Obchodní pohled) s byznysem (Business) a ICT Infrastructure Management (řízení ICT infrastruktury) s ICT Infrastrukturou. V centru všeho jsou dva, často označované jako core (jádro), moduly Service Delivery a Service Support. Tyto dva moduly jsou nejznámější a nejpoužívanější. To vede k tomu, že bývají často vyčleňovány a označovány jako moduly IT Service managementu. Tento názor má své opodstatnění především ve faktu, že se jedná opravdu o dva hlavní a poměrně široce využívané moduly.

1

Zdroj: http://hn.ihned.cz/c1-14454590-itil-a-cobit-ridi-komunikacni-technologie

15

V dnešní době, která má už patřičný odstup potřebný ke zhodnocení tohoto názoru se ukazuje, že se nejedná o zcela korektní vymezení. Spolu s uvedením ITIL V3, který tento fakt ještě více zviditelňuje, je vidět, že ITSM se vztahuje ke všem aspektům řízení poskytování služeb IT, a proto by měl zahrnovat ITIL jako celek a neměl by být omezován jen na již dva zmíněné moduly.1 Charakteristika zbývajících modulů je obsahem Přílohy 1. Obrázek 3. Rámcový model ITIL

Zdroj: Úvodní přehled ITIL®, Copyright itSMF, 2004 [3]

Hlavní cíle IT Service Managementu dle itSMF2 se dají shrnout do následujících bodů: •

Orientace IT služeb směrem k současným a budoucím byznys požadavkům,

•

Orientace všech IT služeb na požadavky zákazníka,

•

Neustálé zlepšování kvality IT služeb společně s dlouhodobou optimalizací nákladů.

2.1.2 Dodávka služeb (Service Delivery) Je dlouhodobě zaměřena na procesy pro plánování a dodávku IT služeb v co nejvyšší kvalitě. Velký důraz je rovněž kladen na neustálé zlepšování poskytovaných služeb. Za tímto účelem používá nástroje jako monitorování a plánování.

1 2

Zdroj: Úvodní přehled ITIL®, Copyright itSMF, 2004 [3] Zdroj: Úvodní přehled ITIL®, Copyright itSMF, 2004 [3]

16

Service delivery obsahuje tyto disciplíny: •

Správa úrovně služeb (Service Level Management) - SLM představuje hlavní interface mezi IT organizací a byznysem. Primárním úkolem tohoto interface je zajištění kvality poskytovaných IT služeb za cenu, kterou je byznys ochoten zaplatit. SLM se dále zabývá plánováním, koordinací, navrhováním, uzavíráním, monitorováním a vyhodnocováním smluv o poskytování servisní podpory.

•

Správa kapacit (Capacity Management) – je disciplína, která zajišťuje, že IT infrastruktura

je poskytována v pravý čas,

v požadovaném

množství

za

požadovanou cenu a je využita s maximální efektivitou. •

Správa dostupnosti (Availability Management) – představuje proces zajištující dostupnost aplikací na základě podmínek stanovených v SLA. V případě výpadku zjišťuje příčinu a zajišťuje opravná a preventivní opatření.

•

Správa kontinuity služeb IT (IT Service Continuity Management) – je proces řízení událostí, jenž mohou mít fatální vliv na dostupnost poskytovaných služeb. Případné hrozby jsou proaktivně vyhledávány, plánovány (plány na obnovu funkčnosti IT infrastruktury v mezích požadovaného časového horizontu). Možnosti výskytu těchto událostí jsou

maximálně redukovány a případná

zranitelná místa jsou ošetřena. •

Správa financí pro služby IT (Financial Management) – představuje disciplínu, která zajišťuje co možná nejefektivnější nákup IT infrastruktury (nejefektivnější automaticky neznamená nejlevnější). Náklady na infrastrukturu jsou rozděleny do tří skupin: zařízení, software, organizace. Na základě těchto parametrů je možné vypočíst náklady na provoz aplikace a návratnost investice. Díky těmto parametrům je možné nastavit cenu byznysu.

2.1.3 Podpora služeb (Service Support) Je modul zabývající se procesy potřebnými pro každodenní podporu a údržbu poskytovaných IT služeb. Service Support obsahuje tyto disciplíny: •

Service Desk – je na rozdíl od ostatních disciplín Service Supportu funkcí a nikoliv procesem. Service Desk zde představuje centrální místo kontaktu (SPOC1) mezi

1

Single Point Of Contact

17

poskytovatelem služeb (IT organizací) a uživateli služeb - byznysem. Jednou ze základní funkcí SD je řešení incidentů, kdy zákazník nemusí zdlouhavě pátrat, kdo mu s jeho problémem pomůže, a zároveň IT podpora není přehlcena nerelevantními požadavky a řeší jen to, co dle své specializace řešit má. Dalším funkcím a nedostatkům Service Desku (v oblasti Change managementu) v jeho konkrétní podobě HP Service Desk, je věnována kapitola 5.1. •

Konfigurační management1 (Configuration Management) – je zaměřen na vedení (identifikaci, kontrolu, udržování a ověřování) uceleného přehledu o logické struktuře IT infrastruktury. Veškeré takto získané informace jsou uchovávány v centrální databázi nazývané CMDB2. Tato databáze obsahuje nejen veškeré technické informace o zařízení a provozovaných službách, ale také konkrétní vazby mezi jednotlivými zařízeními či službami. Jednotlivé konfigurační položky v databázi se označují jako Configuration Item (CI). CMDB je základním zdrojem informací pro ostatní ITIL procesy, proto je nutné, aby kvalita uložených informací o jednotlivých CIs byla co možná nejvyšší.

•

Správa incidentů (Incident Management) – je možné jednoduše popsat jako způsob, jakým Service Desk řeší každodenní incidenty. Incident je specifický typ události nebo uživatelského hlášení, obvykle spojený s událostí, jenž způsobí nebo může způsobit přerušení nebo snížení kvality poskytovaných služeb. Hlavní prioritou Incident Managementu je obnovení standardního provozu služby, a to v co možná nejkratší době při současné minimalizaci dopadů výpadku služby na zákazníka.

•

Správa problémů (Problem Management) - je proces, který se primárně zabývá identifikací a odstraňováním chyb v IT infrastruktuře, které by jinak zapříčinily opakovaný výskyt incidentů. Problem management má spíše reaktivní charakter zaměřený na detailní analýzu klíčové příčiny selhání. Výsledkem takové analýzy je nalezení a definice systémové příčiny incidentu tzv. známé chyby (Known Error3). Přestože je primárním aspektem Problem managementu reaktivní činnost, může být Problem management zaměřen i proaktivně. V tom případě se zaměřuje na

1

itSMF překládá jako Správa konfigurací Configuration Management Database – databáze konfiguračního managementu 3 Known Error – představuje problém, u kterého byla identifikována příčina, přičemž již existuje permanentní popř. dočasné řešení tohoto problému. Často se nalezený problém týká CI nebo skupiny CIs.. 2

18

identifikaci a řešení problémů a známých chyb ještě předtím, než

nastanou

incidenty. Výstup Problem managementu se může stát formálním vstupem Change management procesu, a to v podobě Request for Change (RFC) – požadavku na Změnu. Ostatní výstupy mají podobu zmíněných Known errors, Workarounds1. •

Správa releasů (Release Management) – je disciplína zodpovědná za řízení všech softwarových CIs v rámci organizace. Zodpovídá tedy za vývoj, instalaci a podporu všech softwarových produktů. Software je ze své podstaty nehmatatelný produkt, což znesnadňuje jeho řízení. V důsledku toho může být v rámci organizace mnoho různých

verzí

jednoho

produktu

nebo

může

být

mnoho

nelegálních,

nelicencovaných instalací SW produktů. Běžnou praxí Release managementu je proto vytvoření Definitive Software Library (DSL), která obsahuje hlavní kopie veškerého softwaru. Struktura této knihovny je fyzická - poskytuje zmíněné hlavní kopie, a logická - strukturovaný seznam všech verzí SW, odkazující se na fyzickou část knihovny. •

2.3

Řízení Změn dále jako Change Management – je věnována kapitola 2.4

Od ITIL k ITIL V3

Původní verze ITIL obsahovala 31 knih pokrývajících všechny aspekty poskytování IT služeb. Tato původní verze pak byla revidována a nahrazena sedmi, více spojenými a konzistentními knihami (ITIL V2) zastřešenými společným rámcem. Tato druhá verze byla obecně akceptována a je v současné době používána stovkami organizací v mnoha zemích jako základ pro efektivní poskytováni IT služeb. V roce 2007 byla ITIL V2 nahrazena novou, rozšířenou a konsolidovanou verzí 3 ITILu, kterou tvoří 5 základních učebnic pokrývajících životní cyklus služby, společně s oficiálním úvodem obsaženým v separátním svazku. Každá jednotlivá služba je uvažována v kontextu byznysu.

1

Workarounds je neobvyklé řešení problému, u kterého nelze použít známou metodologii, a to z toho důvodu, že je pro vyřešení nedostatečná. Tato řešení jsou většinou dočasná, jejich primárním cílem je minimalizace následků u vzniklého problému. Jakmile dojde k identifikaci příčiny problému (root cause), Workarounds se stáva Known Error.

19

Obrázek 4. Model ITIL V3

Zdroj: itSMF [4]

Každá z pěti základních učebnic pokrývá jednu fázi životního cyklu, od výchozí definice a analýzy byznys požadavků ve Strategii služby (Service Strategy) a Návrhu služby (Service Design), přes migraci do produkčního prostředí v rámci Přechodu do produkce (Service Transition) a následně Provozu služby (Service Operations) po její Neustálé Zlepšování (Continual Service Improvement). Šestá kniha, Oficiální úvod, nabízí přehled pěti základních učebnic a úvod do řízení IT služby (IT Service Management) jako takové. Pět výše zmíněných knih tvoří základ ITIL V3. Jejich obsah je dále rozšířen doplňkovými publikacemi a souhrnem podpůrných www stránek, zahrnujících např. formuláře, speciální oblasti zájmu jako outsourcing, informace o shodě se standardy, studijní materiály, příklady a podobně. Strategie služby - Díl je klíčovým v rámci popisu životního cyklu. Všem poskytovatelům služeb a jejich zákazníkům poskytuje návod s cílem fungovat a dlouhodobě prosperovat na základě stanovení jasné strategie. Návrh služby - Tento proces se zabývá návrhem vhodných a inovativních služeb včetně jejich architektury, procesů, předpisů a dokumentace, s cílem splnit současné a budoucí požadavky byznysu. Přechod služby do provozu - Tento proces přebírá balíček návrhu služby od předchozího procesu a dodává do provozu řešení, které obsahuje všechny díly potřebné pro trvalý provoz a podporu této služby, jak bylo požadováno byznysem. Autorem popisovaný Change management je součástí tohoto procesu.

20

Provoz služby - Toto je jediná fáze životního cyklu, ve které služby skutečně přinášejí hodnotu byznysu a je zodpovědností zaměstnanců provozu zajistit, aby tato hodnota byla dodána. Cílem tohoto procesu je dodat takovou úroveň služby, která byla dohodnuta s uživateli a zákazníky. A dalším cílem je řídit aplikace, technologie a infrastrukturu podporující dodávku služeb. Neustálé zlepšování služby - Proces poskytující organizaci návod, jak identifikovat a řídit vhodné vylepšování a to tím způsobem, že staví do kontrastu stávající pozici a hodnotu poskytovanou byznysu a naproti tomu dlouhodobé cíle, přičemž identifikuje mezery, které mezi nimi existují. Toho je dosaženo jedině trvalým sledováním změn v požadavcích byznysu, technologie a sledováním toho, že je udržována vysoká kvalita. Hlavní rysem verze 3 je přístup založený na životním cyklu služby a v tomto pojetí rozšiřuje obecně známý Demingův cyklus: PDCA (Plan-plánovat, Do-realizovat, Checkpřezkoumat, Act-reagovat). Obrázek 5. Demingův cyklus

Zdroj: Vlastní tvorba

Následující obrázek popisuje mapování procesů mezí ITIL verzemi V2 a V3. Obrázek 6. Mapování procesů ITIL V2 – ITIL V3

Zdroj: http://www.casewise.com/NR/rdonlyres/7764B00A-EA54-46B4-9988-

21

2.4

ITIL Change management

Je další v řadě disciplín IT Service managementu, která si klade za svůj hlavní cíl řídit všechny druhy Změn1, které mají vliv na dodávku/dostupnost poskytovaných IT služeb. Nástrojem pro dosažení tohoto cíle je jednotný a centralizovaný proces řízení plánování, schvalování a implementace nazývaný Change management proces. Předmětem Change managementu jsou samotné CI nebo jejich skupiny (CIs). Zjednodušeně řečeno je tedy možné chápat Změnu jako proces přechodu CI/CIs nebo jejich parametrů či vlastností z jednoho definovaného stavu do stavu druhého požadovaného2. Tento fakt odhaluje velmi těsnou vazbu Change managementu a Konfiguračního managementu, jelikož je nutné mít přesné a aktuální informace o CI. Pokud totiž chceme něco měnit, je nutné vědět, co měníme, parametry, které měníme a případné závislosti, které je nutné ošetřit. Pokud se zaměříme na již zmíněný cíl Change Managementu, je možné jej jemněji rozdělit na jednotlivé dílčí cíle: •

Řízení procesů (řídící životní cyklus Změn): Požadavek > Vyhodnocení > Autorizace > Implementace Změn

•

Prevence neautorizovaných3 Změn – pro důsledné dodržování tohoto bodu je vyžadována podpora nejvyššího managementu. Ten zde vystupuje jako autoritativní prvek.

•

Minimalizace rizika a selhání implementace – je již zmíněná vlastnost v úvodu. Týká se především případů uvedení nové či nějak změněné CI do prostředí IT infrastruktury. Je třeba znát možné riziko a minimalizovat možnost jeho vzniku + musí rovněž existovat plán na co nejrychlejší odstranění následků v případě jeho vzniku.

•

Minimalizace byrokracie, která je často s CM spojená – i když je Change management proces velmi dobře veden svým vlastníkem, vzniká především ve vztahu s předchozím bodem celá řada kontrolních mechanismů, jež zvyšují

1

Změna a RFC jsou identické pojmy, které lze rozlišit na úrovní Změny – požadavku něco „změnit“ a RFC – reprezentace Změny v konkrétním nástroji (např. HPSD). 2 Řízení RFC, jenž by nedefinovala cílový stav s tím, že „se časem uvidí“ není možné. RFC je třeba jasně specifikovat a následně specifikované řešení důkladně prověřit. 3 Neautorizované RFC jsou RFC, které neprošly procesem revize a nebyly odsouhlaseny. Implementace takových RFC je díky nerevidovanému a neošetřenému riziku nežádoucí.

22

byrokracii. Proto je nutné tato opatření často revidovat a nastavovat taková, aby jednodušší a méně rizikové Změny nebyly neúměrně zdržovány. •

Zajištění správné analýzy a relevantních vstupů – ověření, že všechny Změny byly patřičně analyzovány a všechny relevantní strany jsou zapojeny do hodnocení dané Změny. Tímto způsobem dochází k revizi případného rizika Změny.

•

Koordinace tvorby, testování a implementace řešení – dle ITIL tento bod zahrnuje koordinaci veškerého úsilí potřebného pro vytvoření, testování a implementaci řešení1.

Výše uvedené cíle zajišťují, že hlavním příspěvkem, který Change management byznysu přináší, je jednak minimalizace zhoršení či přerušení dodávky služeb, na kterých je byznys většinou životně závislý, ale také díky využití jednotného a jasně zaměřeného procesu úspora nákladů a času.

2.4.1 Oblasti aplikace Jak již bylo řečeno, hlavním předmětem Change managementu jsou změny týkající se CIs. Change management má však pole své působnosti daleko širší. Nehledě na to, že CIs mohou mít různou podobu. RFC se tak mohou týkat jakékoliv části IT infrastruktury, služby nebo aktivit. Zde jsou následující příklady oblastí: •

Hardware,

•

Software ,

•

Telekomunikační infrastruktura a SW,

•

Dokumentace (plány, procedury)2 – vztahující se k podpoře či údržbě produkčních systémů,

•

Ostatní infrastrukturní zařízení - např. napájení a chlazení,

•

Tréninkové kurzy.

Change management je ze své podstaty zaměřen na produkční prostředí, kde jsou služby plně využívány byznysem a jsou tedy nastaveny všechny nutné vztahy mezi poskytovatelem a uživatelem služby. Z toho důvodu nejsou obvykle Změny, týkající se 1

Dodržování tohoto cíle je však možné jen do určité míry složitosti Změny. Tato problematika je dále diskutována v praktické kapitole 3.5 Create Change Package. 2 Např. Support model, což je dokument jasně definující zodpovědnosti za jednotlivé části řešení (Podpora HW, OS, aplikací atd.). SLA – dokument stanovující parametry poskytovaných služeb. Procedury řízení IT infrastruktury

23

právě vyvíjených CIs v rámci některého z projektů, zpracovávány (kontrolovány) pomocí Change management procesu1.

2.4.2 Příčiny vzniku Změn Tak jako předchozí cíle je možné i příčiny vzniku Změn podrobněji charakterizovat, jelikož Změna nemusí být jen vždy výsledkem úmyslného záměru něco změnit. Další příčiny vzniku Změn jsou: •

řešení incidentů a problémů – RFC vzniká jako výstup z Incident a Problem managementu. RFC se tak stává prostředkem pro odstranění příčiny vzniku incidentu či problému. Incident a Problem management poskytují nezbytné vstupy pro RFC, jež je následně procesována Change management procesem,

•

uvedení do produkce, upgrade nebo odstranění CI – jak již bylo zmíněno, tento bod se týká především CIs v produkčním režimu,

•

změna byznys požadavků – v tomto případě je iniciátorem změny samotný byznys. Většinou je ustanoven projekt, který pak pomocí Změny dosáhne požadované změny, přičemž není nutné, aby samotné řešení již existovalo před vytvořením RFC,

•

změna v umístění – změna lokace produkčních CIs,

•

změna v legislativě – legislativně nařízená opatření, jež mají vliv na produkční CIs. Příkladem může být zákonem stanovená revize napájecí soustavy vyžadující v některých případech odstávku systémů, a to konkrétně s jedním napájením (systém nemá redundantní zdroj napájení, který by umožnil revizi bez výpadku),

•

změna v produktu či službě od dodavatele – např. stávající HW či SW není možné dále podporovat, jelikož dodavatel ukončil oficiální podporu konkrétního produktu. IT organizace proto nemůže dále podporovat stávající řešení a garantovat stanovená SLA. Změna vniká jako prostředek migrace řešení na dodavatelem podporovanou verzi.

2.4.3 Change management a okolní procesy Změny (RFC) mohou být a také většinou jsou velmi komplexní, tak jako služby, které přinášejí. V zájmu udržení požadované kvality a parametrů řešení je nutné, aby byl Change

1

Pro tyto případy lze v praxi nastavit podstatně jednodušší proces, pokud si to okolnosti žádají.

24

management propojen s okolními procesy používanými pro kontrolu a řízení projektů či rozsáhlejších programů vyvíjených v rámci produkčního prostředí. Change management pak vystupuje jako centrální autorita, mající přehled a kontrolu nad všemi Změnami. Následující obrázek shrnuje tato zmíněná propojení. Již byla zmíněna těsná vazba Change a Configuration managementu, který má za úkol identifikovat všechny ovlivněné CIs a následně aktualizuje CMDB. Service Delivery má za úkol posoudit dopad na související služby. Release management má za cíl uvolnění změněného CIs. Obrázek 7. Propojení CM s okolními procesy

Zdroj: Vlastí úprava na základě: ITIL Service Manager for Service Support [1]

2.4.4 Druhy a klíčové elementy RFC Change management je - stejně jako celý ITIL - dobře škálovatelný. V podání Change managementu to znamená, že CM proces musí podporovat řízení různých druhů Změn. ITIL definuje tyto druhy: •

Malé nebo komplexní – rozdělení dle velikosti a složitosti Změny (úprava stávající služby není tak náročná jako implementace nové služby, složité Změny si rovněž vyžadují větší pozornost při revizích a schvalování oproti jednoduchým, kde stačí prověřit jen některé vstupní parametry).

•

S minimálním (minor) nebo veliký (major) dopadem – toto je rozdělení Změn podle možného rizika, které Změna svou implementací přináší. Toto rozdělení umožňuje nastavit jednodušší, rychlejší proces pro minoritní (minor) Změny.

•

V určitý čas – časový úsek, ve kterém musí být Změna dodána .

•

Urgentní Změny – jsou Změny u kterých je vyžadována velmi rychlá implementace. Pro tyto Změny není dostatek času proto, aby mohly projít

25

celým CM procesem. Proto je CM proces podstatně urychlen, jedná se ale stále o proces i když s jinak nastavenými kontrolními mechanismy. Při integraci Change management procesu musí být brán ohled na velikost, strukturu a složitost interních procesů firmy. Change management proces je ze všech ITIL procesů nejvíce „politicky“ citlivý. Proto je nutné, aby byl implementován s ohledem na zmíněné parametry organizace a nebyl vnímán jako byrokratická překážka. Výsledný proces by měl být flexibilní do takové míry, aby byl použitelný v každé situaci, která může nastat.

2.4.5 Change management proces dle ITIL V kapitole Change management a okolní procesy byly popsány základní vazby CM na okolí a rovněž základní workflow Change management procesu. V této kapitole bude postupně popsán CM proces, tak jak jej ve své “základní“ verzi definuje ITIL. Právo vytvořit Změnu mají všichni zaměstnanci v rámci dané organizace, a to zejména kvůli inovačním aktivitám nebo upozornění na závažné nedostatky. Přičemž Změny od běžných uživatelů jsou nejdříve revidovány liniovým vedoucím nebo jinou odpovědnou osobou, aby se zabránilo duplicitním nebo nepraktickým RFC požadavkům. Naopak Změny od technických pracovníků touto kontrolou procházet nemusí – předpokládá se, že požadavek je dostatečně věcně a technicky korektní. Change manager vystupuje jako první filtrační prvek, který filtruje neúplné, nežádoucí nebo opakující se požadavky. Change manager dále přiřadí prioritu na základě posouzení dopadu a urgence Změny. Pokud RFC předchází Incident či Problém je priorita RFC nastavena již Problem managementem. Příklady definice priorit: High – vysoká priorita, ztráta důležité služby a dopad na mnoho uživatelů. Jedná se o přednostní prioritu v rámci Change management procesu. Medium – střední priorita, není zde přímý dopad na dostupnost služby, ale není možné čekat na nový release nebo upgrade služby. Low - nízká priorita, RFC je plně odůvodnitelná, ale je možné čekat např. do uvedení nové verze (release) nebo aktualizace stávající verze (upgrade).

26

Obrázek 8. Úvodní evidence Změn

Zdroj: Vlastí úprava na základě: ITIL Service Manager for Service Support [1]

Kromě zmíněných priorit ITIL definuje ještě jeden specifický druh priority urgentní (urgent). Implementace urgentních Změn pomocí celého - základního1 Change management procesu by byla příliš pomalá, proto existuje jeho zrychlená verze - urgentní proces zajištující co nejrychlejší implementaci. Změnový model na Obr. 8 ukazuje ještě další možnou cestu určitého druhu procedurálních Změn, které nemusí procházet celým Change management procesem, ale jen jeho zjednodušenou variantou. Jedná se o rutinní pre-autorizované RFC, jako např. vytvoření uživatele, změna hesla, rozšíření místa na serveru. Poslední částí, kterou popisuje Obr. 8., je Kategorizace RFC. Kategorizace je parametr, sloužící k nastavení typu RFC, jenž pak prochází daným modelem Change management procesu. Při kategorizaci se bere v úvahu dopad, náklady, potřebné lidské zdroje a časová náročnost vývoje RFC. ITIL definuje tři základní kategorie: Minor (méně závažné), Significant (důležité) a Major (závažné). Přičemž primární rozdělení je dle požadavku na potřebné zdroje. Následující části Change management procesu, které budou zmíněny, na sebe plynule navazují a nejedná se o samostatné části. Z důvodu lepší přehlednosti jsou však rozepsány postupně. 1

ITIL definuje tento základní proces jako Standard Change Management process. Jedná se o nejdelší – celou variantu CM procesu

27

Obrázek 9. Posouzení a Schválení RFC

Zdroj: Vlastí úprava na základě: ITIL Service Manager for Service Support [1]

V předchozí části byl popsán vznik RFC včetně úvodní filtrace a následného rozdělení resp. zpracovávání RFC. Obr. 9. popisuje další část Change management procesu zabývající se schvalovacím procesem, který se odvíjí od RFC kategorie, jenž byla určena Change managerem. Zastavme se nyní u této části procesu. Jakmile je definována kategorie RFC, je možné přejít k jejímu schválení. U základního typu Minor je schvalovací autoritou Change manager, který rozhoduje i o naplánování implementace Změny. Veškerá rozhodnutí by však měla být prezentována CAB komisi (Change Advisory Board), která v případě jakýchkoliv pochybností může rozhodnout o nutnosti dodatečného schválení CAB komisí. Veškeré Minor Změny by měly být rovněž zaznamenávány pro účel další analýzy jako např. analýza přesných nákladů pro danou službu, identifikace opakujících se Změn nebo určitých trendů apod. V případě kategorie Significant se jedná o Změny, jež vyžadují pozornost a schválení CAB komise, jelikož Change manager již nemůže dostatečně posoudit daný rozsah Změny. Za tímto účelem Change management zajistí distribuci všech Significant Změn (agendy) před dalším/následujícím CAB meetingem. Běžně se jedná o distribuci informací všem standardním účastníkům1 CAB meetingu, ale pokud si to situace žádá Change management přizve a informuje další potřebné specialisty.

1

Možní členové CAB komise: Change manager (jenž řídí CAB meeting), manažeři ze strany zákazníka byznysu, zástupci a manažeři ze strany uživatelů, aplikační podpora a vývoj, techničtí specialisté (např. operations, síťový specialisté) a dále zástupci třetích stran

28

Změny kategorie Major se vyznačují tím, že jejich rozsah je natolik závažný, že před schválením CAB komisí musí Změnu schválit CIO1 nebo ředitel IT a to v rámci výkonné rady organizace. Z hlediska posouzení dopadu by se CAB komise měla zaměřit na tyto oblasti:
dopad Změny na byznys popř. na další byznys infrastrukturu,
dopad na IT infrastrukturu a službu samotnou,
dopad na okolní služby,
následky vyplývající z odmítnutí implementace Změny,
IT a byznys zdroje potřebné k implementaci Změny.
aktuální plán připravovaných služeb (FSC)2 a plánovaná dostupnost služeb (PSA)3. Všechny tyto faktory musí být vyváženy s potenciálním přínosem a prioritou Změny. Pokud je Změna komplexně revidována, je možné přejít k fázi schvalování. Tato fáze byla již zmíněna u kategorie Minor Změn. V zásadě každá Změna musí být schválená a není vyloženě nutné, aby se autorizační autoritou stal přímo Change manager nebo CAB komise. Změnu může schválit např. Service Manager starající se o neustálou spokojenost zákazníka nebo to může být jiná pověřená osoba. Change manager však zde stále vystupuje jako nejvyšší autorita zajištující dohled. Může kdykoliv a jakkoliv zasahovat do probíhající Změny. Obsah formální části schvalovacího procesu popisuje následující tabulka: Tabulka 3. Formální části schvalovacího procesu Náklady na Změnu odpovídají stanovené výši nákladů. Finanční souhlas Technický souhlas Změna je realizovatelná, má smysl a neobsahuje nežádoucí dopad na IT služby. Změna je chtěná byznysem a byznys rovněž akceptuje dopad Změny Byznys souhlas Zdroj: Vlastí úprava na základě: ITIL Service Manager for Service Support

Jakmile je Změna schválena, příslušní techničtí specialisté mohou začít pracovat na přípravě požadovaného řešení – Změny. Po vlastním vývoji je nutné Změnu otestovat a

1

Chief Executive Officer - výkonný ředitel FSC – Forward Schedule of Changes – plán implementace připravovaných RFC poskytující přehled o časech, plánech, povoleních ze strany byznysu a schválený výpadek - downtime služby. Jedná se o dokument či aplikaci dostupnou na podnikovém intranetu. 3 Projected Service Availability – je dokument používaný Change managementem pro vyjádření dopadu RFC na dostupnost služeb stanovených v SLA – jinými slovy vyjádření plánového výpadku služby. Tento dokument musí být odsouhlasen zákazníkem/byznysem a Availability managementem. 2

29

připravit back-out1 plány, které slouží pro navrácení služby/CI do původního definovaného stavu před implementací v případě neúspěšné implementace Změny. Change management v této přípravné fázi vystupuje jako koordinátor spolu s Release managementem a odpovědnými liniovými vedoucími. Obrázek 10. Tvorba a implementace Změn

Zdroj: Vlastí úprava na základě: ITIL Service Manager for Service Support

Implementaci Změny řídí opět Change manager s tím, že všechny strany účastnící se implementace jsou o plánech dostatečně dlouho dopředu informovány (například přes Service Desk). Implementaci je nutné naplánovat na dobu, kdy je dopad na byznys nebo další služby minimální. Aplikační a další podpora musí být připravena v případě incidentů nebo dalších servisních požadavků ihned zasáhnout. Pokud implementace selže, je nutné implementovat back-out plán a uvést službu zpět do předchozího nebo jasně definovaného funkčního stavu. Po implementaci následuje závěrečná revize (review) Změny. Tato revize se koná po určité stanovené době, aby bylo možné s odstupem času posoudit, zda bylo dosaženo požadovaného cíle či nikoliv. Součástí této revize je i hodnocení přesnosti odhadovaných nákladů a zdrojů, které může zpřesnit budoucí odhady. Závěrečné revize se může účastnit i CAB komise, a to zejména v případech, kdy následují navazující (follow up2) aktivity. Jakékoliv zjištěné nesrovnalosti by měly být reportovány CAB komisi.

1 2

Back-out nebo také roll-back Zpětné zjišťování a vyhodnocování

30

Závěrečná revize by měla ověřit, zda:
změna splnila stanovené cíle,
uživatelé jsou spokojeni s výsledkem,
nevyskytly se žádné nečekané nebo nežádoucí vedlejší efekty,
potřebné zdroje jsou v souladu s plánovanými,
Změna byla implementována dle stanoveného plánu a nákladů,
back-out plán byl úspěšně implementován. Jakékoliv další případné Změny musí být opět evidovány formou RFC a jsou řešeny pomocí dalších Změnových požadavků. Závěrečným krokem této fáze je dokumentace. Change manager je v tomto případě zodpovědný za aktualizaci veškeré dokumentace, což jsou:
uživatelské a technické manuály,
procesní dokumentace,
CMDB resp. informace v CMDB uložené.

31

3 Change management v datovém centru V této kapitole, jak je již z názvu patrné, se autor věnuje implementaci Change management procesu v datovém centru. Konkrétně se jedná o společnost DHL Information Services, s.r.o (dále jen jako DHL IS, ITS nebo datové centrum). DHL IS je organizace poskytující IT služby mateřské společnosti DP DHL (dříve DPWN1). Pod DP DHL spadají Deutsche Post a veškeré části přepravní společnosti DHL. Poté, co DP DHL dokončila akvizici celé přepravní společnosti DHL spolu s dalšími společnostmi doplňujícími strategické záměry společnosti, bylo rozhodnuto o migraci datového centra z Londýnského Staines do Prahy. Součástí této migrace byla i rozsáhlá konsolidace a migrace IT služeb z lokálních center vybraných států Evropy. Výsledkem bylo velmi různorodé prostředí, a to jak z pohledu hardware, software ale i procesů. Jelikož se jedná o podporu hlavních (core) byznys procesů, zavedení a použití jednotného procesního řízení co nejvyšší kvality bylo naprostou nutností. Díky migraci z datových center ve Velké Británii, bylo možné navázat na tamní procesy implementované podle ITIL. Ty však bylo potřeba sjednotit a přizpůsobit na míru nově vznikajícímu datovému centru v Praze. Velikost firmy a firemní procesy se změnily podstatným způsobem a spolu s tím se podstatně zvýšily i nároky na kvalitu poskytovaných služeb. Nemalou roli při zaměření na zlepšení kvality sehrála poměrně vysoká skepse ze strany zákazníků, kteří díky konsolidaci přicházeli o svá lokální IT střediska a byli tak postaveni nákupem svých IT služeb z pražského datového centra před hotovou věc.

3.1

Základní2 Change management proces

Change management proces je na první pohled proces v organizaci jako každý jiný. Dle pravidel procesní organizace by měl být neustále revidován a upravován na míru současným požadavkům a prostředí organizace. V tomto ohledu není společnost DHL IS žádnou výjimkou. Avšak při druhém mnohem detailnějším pohledu, jenž bude součástí 1

Deutsche Post World Net Jak již bylo zmíněno v teoretickém části popisu ITIL Change managementu, neexistuje žádná standardní nebo nestandardní verze Change management procesu. Autorovo označení pouze symbolizuje fakt, že se jedná o jeden „základní“ Change management proces, který je pro různé typy a priority Změn růžně dlouhý (složitý). V základu se, ale stále jedná o jeden a ten samý Change management proces pružně reagující na požadavky, jež umožňuje rychlejší reakci na nejen byznys požadavky implementace Změn. 2

32

následující třetí kapitoly, bude prakticky popsán jeho klíčový přínos - možnost poskytovat IT servisní organizaci velmi mocný nástroj pro kontrolu a koordinaci všech aktivit spojených s poskytováním IT služeb. Change management proces ve společnosti DHL IS prošel již mnoha změnami a je neustále revidován. Od své výchozí verze, která primárně vycházela z ITIL V2, je dnes podstatně rozšířen, přičemž tempo jeho vývoje je v posledních dvou letech podstatně vyšší, než tomu bylo dříve. Existují pro to dva hlavní důvody: restrukturalizace společnosti a s tím spojené nové projekty. Na Obr. 11. je znázorněn základní Change management proces ve formě navazujících bloků, kterým budou věnovány následující kapitoly. Tyto bloky znázorňují části Change management procesu a přehledně tak vymezují části životního cyklu Změny. Zmíněné bloky budou nejdříve stručně charakterizovány jako black box1, nicméně dále bude popsán jejich účel, vnitřní logika a budou porovnány s ekvivalentní procesy dle ITIL, pokud to bude možné.

Obrázek 11. Schéma DHL Change management procesu

Zdroj: Vlastí úprava na základě dokumentů DHL

1

Black box – černá skříňka. Popisují se jen vstupy a výstupy, přičemž vnitřní mechanizmus zůstává skrytý

33

3.2

Change initiation

Vstup: RFC iniciátor (requestor) pošle žádost o Změnu – Request for Change Výstup: Change managementem filtrovaný, prioritizovaný a zařazený RFC nebo odmítnutý RFC Typ změn: Release, Routine Statusy Změny v této fázi: RFC, Registered Je úvodní fází Change management procesu, kdy RFC iniciátor (dále jako requestor) vytvoří RFC – požadavek na Změnu. Zaměřme se nyní na okolnosti vzniku RFC. Důvody vzniku RFC jsou z valné části shodné s uvedenými důvody na straně 24. (např. řešení incidentů a problémů, uvedení do produkce, změna byznys požadavků atd.). V tomto ohledu je pojetí servisní organizace DHL shodné s pojetím definované v ITIL, tudíž zde není větších rozdílů. Drobné rozdíly je možné nalézt při zaměření se na osobu requestora. Mezi hlavní skupiny RFC iniciátorů patří projektové týmy v čele s projektovým manažerem (PM), skupiny aplikační podpory, zákazník (většinou aplikační nebo vedoucí pracovníci) a v neposlední řadě lokální Change management skupiny v různých zemích. Oproti teoretické části ITIL Change managementu, která primárně hovoří o produkčních1 systémech, pamatuje DHL Change management proces i na testovací2 prostředí. V tomto případě se ale jedná pouze o buildovací3 Změny. Přičemž případné změny konfigurace testovacích systémů jsou většinou řešeny pomocí Service callu4, jelikož se nejedná o přímé ohrožení produkční služby. V případě implementace požadavků pomocí RFC požadavku by byla požadovaná Změna neúměrně opožděna vzhledem k možnému riziku vlastní implementace. Nyní se přesuňme k popisu samotného RFC požadavku. Ve společnosti DHL IS je používán produkt HP Service Desk (dále jako HPSD, tomuto SW nástroji je věnovaná část kapitoly Nástroje pro implementaci). Tento SW produkt je navržen pro podporu Change managementu, Service Desku a dalších procesů vycházejících z ITIL doporučení. HPSD funkcí je poskytnout centrální místo kontaktu (SPOC) mezi uživateli/byznysu a IT Service Managementem, který tyto služby zajišťuje a řídí jejich chod. 1

SLA pro produkční prostředí je 24x7 (24 hodin, 7 dní v týdnu) SLA pro testovací prostředí je 8x5 (8 hodin denně, 5 dní v týdnu) 3 Build RFC – slouží pro vytvoření (postavení) nového prostředí dále využívaného jen pro testovací účely 4 Service call – jednoúčelový požadavek v HPSD používaný pro řešení incidentů, rutinních požadavků a úkolů. 2

34

Obrázek 12. RFC v HPSD nástroji

Zdroj: Vlastní tvorba (DHL HPSD)

Na Obr. 12. je zachycen reálný RFC formulář (template) otevřený v HPSD nástroji. Základním identifikačním parametrem každého RFC je pole1 číslo RFC (ID), které je pro každé RFC jedinečné. Status (stav) slouží pro jednoduchou viditelnost, v jaké fázi se RFC nachází (jednotlivé stavy jsou v následujících částech CM procesu popsány).

Jméno

Requestora (RFC iniciátor). Service definuje, k jaké službě je RFC vázána. Description je krátký popis RFC sloužící pro identifikaci (tak jako Subject v případě emailu). Information je delší textový popis, do kterého se informace píší pomocí okna Information update; zde je možné více popsat RFC nebo se odkázat na jiné sdružené RFC, Incidenty apod. Pole To Workgroup a To Person slouží pro přiřazení RFC konkrétní skupině a konkrétní osobě ve skupině, která tuto RFC uvidí ve své HPSD frontě. Další pole Registered je vyplňováno automaticky systémem a zachycuje datum vytvoření RFC. Následuje Planned Start/Finish, což je specifikace požadovaného časového okna implementace. Pole Category, Change Priority, Byznys Impact popisují kategorii, prioritu a geografický dopad na byznys. Ostatní informační pole Outside Maintenance Window slouží pro specifikaci, zda je RFC plánována do časového úseku, kdy má služba pravidelnou odstávku. Reason/caused informuje o příčině vzniku RFC. 1

Pole nadepsaná tučně musí být při vytváření RFC vyplněna – jsou povinná

35

Z předchozího popisu je vidět, že samotný HPSD RFC formulář sice zachycuje celou škálu podstatných parametrů, ale pro komplexní popis či pochopení Změny, které je nutné pro důkladnou revizi, to není plně dostatečné. Z tohoto důvodu existuje dodatečný dokument, který je nedílnou součástí Změny, a tím je Change Management checklist (dále jako CM checklist). CM Checklist je excelový dokument skládající se z více částí, které jsou ve formě záložek. Těmito částmi jsou: CAB checklist, IQG checklist, RTP a Communication

plán.

Účel

těchto

jednotlivých

vnořených

dokumentů

bude

v následujících kapitolách postupně popsán. CAB a IQG checklist obsahují celu řadu doplňujících otázek, sloužících k detailnímu

popisu Změny. CM checklist je vložen

formou přílohy do RFC formuláře v HPSD. Tak je zaručeno, že všichni, kdo RFC revidují/schvalují, vždy používají stejnou verzi tohoto dokumentu. Vraťme se nyní zpět k Change initiation fázi. CAB checklist, jenž je pro tuto fázi stěžejním zdrojem informací, je představován sadou generovaných otázek, na které musí requestor odpovědět. Generování probíhá automaticky podle zvolených možností definující rozsah (scope) Změny (viz. Obr.13.). Tento způsob zaručuje sestavení relevantních otázek, které revidujícímu, pomáhají plně pochopit rozsah Změny. To umožňuje jednodušší a efektivnější práci. Následující obrázek zobrazuje způsob, jakým se definuje urgentní Změna ve stávajícím produkčním prostředí. Na základě zobrazených předvoleb se vytvoří konkrétní CAB a IQG checklist.

Obrázek 13. CM Checklist - Definice rozsahu Změny

Zdroj: Vlastní tvorba (DHL CM Checklist)

36

Tímto efektivním způsobem je do jisté míry zabezpečena kvalita vstupních informací (requestor není zmaten z mnoha nerelevantních dotazů) a jasný přehled o požadavcích, rozsahu a následků Změny. Výsledné otázky jsou navíc strukturovány do logických bloků (např. otázky týkající se bezpečnosti nebo vlivu na síťovou infrastrukturu, projektu), což podstatným způsobem ulehčuje a zrychluje orientaci. V každodenní praxi je velmi důležitým parametrem srozumitelnost a s tím spojená kvalita vyplňovaných informací. I když je CAB checklist velmi přehledně uspořádán, je nutné při jeho vyplňování srozumitelně popsat parametry požadované Změny. Ve většině i případů neúplný, ale srozumitelně vyplněný checklist poskytne více informací, nežli jeho opak. Následná diskuze a spolupráce mezi zúčastněnými stranami je daleko jednodušší a konstruktivnější. Celý CM checklist urazil poměrně dlouhou cestu a změnil se z původně statického, těžkopádného a poměrně byrokratického dokumentu, na dnes velmi užitečný nástroj, jistým způsobem zaručující vysokou a konstantní kvalitu informací. Je však nutné dbát na dva základní předpoklady: 1. Existuje vlastník CM checklistu, který jej pravidelně reviduje a aktualizuje – ideálně Change management nebo další skupina která jej nejvíce využívá. 2. Všichni, kdo CM checklist v průběhu Change management procesu revidují, se snaží o co nejlepší kvalitu informací tj. upřesnění nejasných odpovědí Pro requestora je to užitečný nástroj pro vytříbení jeho vlastních požadavků a zároveň požadavků, které bude třeba v následujících fázích vyřešit. Pokud se vrátíme využití zmíněného CM checklistu v této fázi, je to především Change manager/analytik, pro kterého je CM checklist zdrojem základních informací pro posouzení správnosti a proveditelnosti RFC. Change management1 kontroluje rozsah Změny, základní informace o zasažených (impacted) serverech či službách. Dále všechny důležité časové milníky Změny ve spojitosti s důležitými milníky CM procesu (tj. kontrola zda je možné RFC v daném čase schválit a implementovat). Change management v této fázi spolupracuje přímo s requestorem na odstranění či vyjasnění případných nedostatků.

1

Autor dále ve své práci používá označení “Change management“ pro označení celého Change management oddělení, které zahrnuje Change managera a Change analytiky. Toto označení se v praxi běžně používá v případech, kdy nezáleží na konkrétní roli uvnitř CM, ale na celém oddělení Change managementu.

37

3.2.1 Kategorizace změn podle rozsahu Na Obr. 13. byly již vidět první náznaky dělení Změn. Pojďme si proto v následujících podkapitolách popsat jednotlivé parametry, podle kterých se Změny dělí, a jak toto dělení ovlivňuje jejich životní cyklus. První způsob dělení, který zásadním způsobem ovlivňuje další pouť RFC požadavků, vychází z rozsahu Změny. Jinými slovy se jedná o rozdělení dle vlivu Změny na své okolí. Tento způsob rozdělení rozlišuje dva druhy Změn, které podrobněji charakterizuje následující tabulka.

Typ změny

Release

Routine

Tabulka 4. Release a Routine kategorie Změn Popis   

Uvedení nového HW do provozu Uvedení nové služby do provozu Uvedení nové verze existující služby nebo jakákoliv nová funkcionalita stávající služby  Nasazení již existující služby do nových zemí, regionů nebo pro nové zákazníky  Komplexní infrastrukturní změny Tento typ Změn přináší něco nového. Proto je třeba důkladně posoudit jejich obsah a případný vliv. Změny tak podléhají schválení CAB komisí a implementační IQG komisí. Jsou změny týkající se přidání, smazání nebo modifikace produkčního nebo testovacího prostředí. Nejedná se o nový release služby nebo její nové funkcionality. Tento typ Změn není třeba schvalovat CAB komisí, a to z toho důvodu, že se jedná jen o úpravy stávajícího prostředí aplikace či služby. Tento typ změn podléhá schválení jen IQG komisí. Př. Upravení aplikace (formát zpracovávaných/přeposílaných dat) Zdroj: Vlastní tvorba

U Změn typu routine může být requestorem jak projektový manažer (dále také jako PM), tak byznys IT, nebo vlastník aplikace (Service owner - SO), potažmo interní pracovník datového centra. V případě release Změn (dále také jako Projektová Změna) je requestorem obvykle projektový manažer, jelikož v pozadí takových Změn stojí většinou sponzor – requestor Změny. V obou případech uvedených typů Změn funguje jakási pojistka v podobě vyžadovaného souhlasu od Senior managera requestora, která tak zajistí jistou kontrolu požadované Změny. Pro routine i release Změny je nežádoucí, aby

byl requestorem přímo koncový

zákazník/uživatel, který by nekoordinovaně požadoval například funkční změnu aplikace.

38

Přestože se zmíněné rozdělení Změn může zdát jako velmi jednoznačné, v praxi dochází k situacím, kdy je tato jednoznačnost poměrně těžko dosažitelná nebo není v zájmu zákazníka úplně vhodná. V těchto situacích má rozhodující slovo Change manager, jakožto vlastník procesu. Ten pak může třeba i pomocí doplňujících opatření (většinou ve formě dodatečných schválení), povolit implementaci změny routine procesem, přestože dle uvedené definice se spíše jedná o release RFC. Tento způsob jednání však v žádném případě nelze chápat jako cestu obcházení procesu či ulehčování si práce. Pokud si vezmeme příklad implementace Změny ovlivňující některé okolní služby, může se jednat o zcela minoritní vliv, který může být již dopředu prověřen popř. ošetřen nebo ošetření je součástí jiné Změny, jejíž implementace bude předcházet implementaci této Změny. Je tedy na Change managerovi, aby všechny tyto okolnosti zvážil s ohledem na důležitost (urgenci) RFC pro zákazníka a stanovil vhodný proces (postup) tak, aby se Change management proces nestával zbytečnou překážkou. Tímto se dostáváme k dalšímu parametru Změn, riziku podle kterého se dále dělí.

3.2.2 Kategorizace Změn podle úrovně rizika Pouhé rozdělení dle rozsahu by plně nevystihovalo všechny atributy Změny a výsledný Change management proces by byl poměrně strohý a neflexibilní. Proto jsou zavedeny ještě další parametry, které mají za cíl detailnější popis Změny. Jedním z těchto parametrů je úroveň rizika implementace Změny. Tento parametr určuje, jakým způsobem Změna ovlivňuje nebo může ovlivnit okolní služby. Jednotlivé kategorie jsou shrnuty v následující Tabulce 5. Kategorie pre-authorised (pre-autorizované) představuje rutinní Změny s žádným nebo velmi minimálním rizikem a dopadem na okolní služby. Tento druh Změn neprochází standardním Change management procesem nýbrž speciálním procesem popsaným v Standard Request Change katalogu. Ten jednak samotné pre-autorizované Změny definuje (co je a co není pre- autorizované) a určuje i správnou RFC šablonu (template obsahující předem definované Work Orders, dále jako WO), které má být pro následné schválení a implementaci použity. Příkladem pre-autorizované Změny může být např. změna uživatelských práv na serveru nebo vytvoření skupiny/uživatele. Zpracování minor Změny se již podobá procesování následných složitějších Změn, ale stále se jedná, tak jako v případě pre-autorizované Změny, o Změnu s minimálním rizikem případného negativního dopadu. I v tomto případě je Change management proces výrazně redukován. Tento typ RFC je pro vlastní implementaci schvalován jen 39

Change

managementem (nikoliv CABem). Tak je v zájmu žadatele nastaven schvalovací proces na co nejkratší možnou dobu, ale zároveň tak, aby požadavky byly dostatečně posouzeny a vyhodnoceny. Příkladem implementace minor Změny je požadavek na rozšíření diskové kapacity serveru. Tento požadavek obsahuje dva schvalovací WO. Jeden je pro Capacity management, který posuzuje, zda projekt zažádal oficiální cestou o dodatečné místo a náklady s tím spojené budou uhrazeny (velmi zjednodušeně - musí existovat schválená objednávka na požadovaný prostor). Druhý WO je pro SAN1 tým, který ověří kapacitu současného diskového pole (zda je dostupná požadovaná kapacita v určitém SAN prostředí) . Pokud jsou oba výše zmíněné WO odsouhlaseny, CM udělí konečný souhlas, vytvoří implementační WO na přidání dodatečné kapacity a přiřadí jej do HPSD fronty SAN týmu. Vlastní implementace – přidání dodatečného místa - je provedeno na základě tohoto implementačního WO. Kategorie significant a major jsou Změny podstatně složitější a jejich dopad může být od jedné služby až po celé datové centrum. Tento druh, narozdíl od předchozích Změn, není řízen a schvalován pouze Change managementem. Hlavní důvody proto jsou zejména komplexnost, potřebné technické znalosti a časová náročnost přípravy implementace. Tyto Změny procházejí celým „základním“ Change management procesem a jsou schvalovány CAB a IQG komisí, které budou popsány v dalších kapitolách. Přestože následující příklady jsou uvedeny tak, aby byl rozdíl mezi těmito kategoriemi dostatečně zřejmý, v praxi tyto dvě kategorie splývají. Hlavním důvodem proto je již zmíněný průchod stejným Change management procesem. Rozlišení těchto Změn je tedy spíše formální. Příkladem significant Změny může být vytvoření nové databázové instance (např. pro nového zákazníka) uvnitř sdíleného databázového prostředí (clusteru). V tomto případě může mít neúspěšná instalace vliv jen na okolní databázové instance uvnitř daného clusteru, ale nijak přímo neovlivňuje ostatní nesouvisející servery/služby. Příkladem major změny může být každoroční revize napájení serverů, kdy jsou dočasně vyřazeny postupně obě větve serverových napájejících přívodů. To však v praxi znamená vyšší zatížení neodpojené napájecí větve (druhého zdroje serverů), která takovou změnu zřídka nevydrží. Následkem je nekorektní vypnutí serveru. U uvedeného příkladů je vidět, že předvídání možných problémů je velmi obtížné, ne-li nemožné (pokud neexistuje alespoň nějaká předchozí zkušenost). V těchto případech je jedinou cestou ošetření případného rizika v podobě minimalizace možných následků - incidentů. Jedním z procesních opatření je 1

SAN – Storage Area Network - je speciální dedikovaná síť, která slouží pro připojení externích zařízení k serverům (disková pole, páskové knihovny)

40

vyhlášení tzv. Change freeze – všechny ostatní Změny plánované na stejný časový úsek jsou odmítány (odloženy), aby nedocházelo k případným nežádoucím kolizím a všechny potřebné lidské zdroje měly v tento čas volný prostor na řešení případných kritických situací.

RFC kategorie

Tabulka 5. Kategorizace změn podle úrovně rizika Popis vlastností Jsou definovány ve Standard Request katalogu. Jedná se o nedestruktivní Změny s velmi malým rizikem. RFC musí být třikrát úspěšně implementována, aby bylo možné požádat o pre-authorised klasifikaci (tj. definici v Standard Request Change katalogu). Rozhodnutí o této klasifikaci náleží IQG komisi, která schvaluje jednotlivé RFC pro konečnou implementaci Reprezentují Změny s nízkým rizikem na případnou službu. Většinou se jedná o malou nekritickou část služby nebo samotného zařízení/systému (CI). Implementaci zajišťuje jen jeden tým Signifikantní kategorie RFC představuje Změny s nižší mírou rizika než major kategorie, ale stále se jedná o Změny, které mají případný negativní vliv na mnoho uživatelů. Do significant kategorie spadají automaticky změny, které vyžadují downtime služby. Implementace je zajištěna kooperací různých oddělení/týmů popř. různých byznys útvarů nebo externích dodavatelů Kategorie major jsou typy Změny s nejvyšší mírou rizika narušení produkčních služeb potažmo kritickou částí byznysu. Případný výpadek služby/služeb má vliv na vysoké procento uživatelů nebo kritických systémů pro byznys. Roll back Změny do původního stavu před implementací není možný nebo je velmi komplikovaný Zdroj: Vlastní tvorba

3.2.3 Kategorizace změn podle jejich priority Priorita je posledním z parametrů Změny, který je nutné u každého RFC požadavku charakterizovat. Tento parametr popisuje, jak urgentní je implementace dané Změny. Projekt má právo žádat o nastavení určité priority Změny, konečné slovo má však Change management, který může rozhodnout jinak. Jednotlivé priority mají své náležitosti, které musí requestor splnit (např. potřebná potvrzení, vysvětlení atd.). Tímto opatření se v praxi zamezuje, aby většina neadekvátně časově naplánovaných (bad planning) požadavků Změn nepřicházela na poslední chvíli s prioritou urgent nebo emergency. Jednotlivé priority popisuje následující tabulka:

41

Priorita Low

Medium High

Urgent

Emergency

Tabulka 6. Priorita Změny Popis Implementace Změny není nutně vyžadována, ale její implementace je všeobecně prospěšná. V případě konfliktu s jinou prioritnější Změnou může být implementace posunuta/odložena. Změny s touto prioritou podléhají základnímu Change management procesu Změna s touto prioritou přináší přímý užitek službě na kterou je implementována. Implementace je tedy žádoucí. Změny s touto prioritou podléhají základnímu Change management procesu Priorita high představuje Změny, které jsou pro organizaci velmi důležité. Tudíž jejich implementace musí proběhnout co možná nejdříve. Změny s touto prioritou podléhají rovněž základnímu Change management procesu Urgent je kategorií Změn, u nichž je vyžadována implementace v nejbližší možný termín, ale není dostatek času na jejich přípravu pomocí základního Change management procesu. Důvody pro to jsou většinou neadekvátní projektové plánování nebo urgentní požadavek ze strany zákazníka/byznysu. Změny s touto prioritou podléhají urgentnímu Change management procesu ( viz. kapitola 3.9) Je speciální kategorie neplánovaných Změn. Vznikají jako důsledek incidentů, které ohrožují nebo již ovlivnily dostupnost kritických byznys služeb. Tyto Změny jsou vytvořeny s cílem odstranit vzniklý problém v co možná nejkratší době. Příkladem 1 může být odstranění poruchy HW, instalace kritického patche nebo instalace bug fixu apod. Změny s touto prioritou podléhají emergency Change management procesu ( viz. kapitola 3.9) Zdroj: Vlastní tvorba

3.2.4 Workflow a rozdělení zodpovědností Změna má po svém bezprostředním vytvoření a přiřazení do Change management HPSD fronty status RFC. Schvalování a implementace pre-authorized Změn probíhá již zmíněným mechanismem. Ostatní Změny jsou revidovány a klasifikovány Change analytikem/manažerem. V případě jakýchkoliv nejasností spolupracuje requestor a Change analytik/manažer na vyřešení. Pokud CM Změnu akceptuje, změní status RFC na Registered a Změna je dle přiřazené kategorie posunuta do další fáze. V případě odmítnutí je requestor seznámen s jasnými důvody, proč tomu tak je.

1

Aktualizace, záplata nebo oprava programu – jedná se o menší instalační program opravující chybu dané aplikace

42

Obrázek 14. Change initiation fáze Start Change initiation

Pre-autorised Requestor vytvoří RFC požadavek v HPSD Akceptace RFC

Vrácení requestorovi na doplnění

Revize RFC (kategorizace) Je správně ohodnoceno riziko a priorita?

ANO NE Change Manager/Analytik

Routine/Relase ?

Routine

Release

Konec Change initiation

Odmítnutí

Start Create Change Package

Zdroj: Vlastní tvorba

Zodpovědnosti Change Managementu: 

prvotní revize RFC – „je reálné implementovat RFC v požadovaném datu?“,



kontrola správnosti kategorie RFC (pre-authorised, minor, significant, urgent, emergency),



v případě, že je požadovaná dokumentace kompletní a správná, je možné změnit RFC status na „Risk_Impact“ a postoupit do další fáze. Kontrola správnosti na této úrovni zahrnuje např. posouzení, zdali uvedená služba a k ní patřičný vlastník služby existuje, nebo zdali jsou odpovědi na dané otázky relevantní.

Zodpovědnosti requestora: 

okamžitě po zadání projektu vytvořit RFC,



vyplnění a přiložení CM checklistu (CAB checklistu) popřípadě další projektové dokumentace jako např. schéma architektury a další podpůrné materiály,



přiřazení změny do HPSD Change management fronty.

43

3.3

Change Impact Analysis & Risk

Vstup: plně klasifikovaný a ověřený požadavek na Změnu Výstup: Změna schválená IA/RA komisí (Impact & Risk analýza) Typ změn: Release Statusy Změny v této fázi: Risk&Impact, Rejected Fáze Impact Analysis & Risk Assessment nebo také již zmíněný název Risk_Impact (popř. IA/RA fáze) je první kontrolní fází, při které se reviduje dopad plánované změny a nebezpečí s ní spojená. Hlavní zaměření této analýzy je technický úhel pohledu. Není však jediným, což je více viditelné ze složení IA/RA komise popsané níže. Vraťme se ale ke zmíněnému technickému pohledu. Příchozí release Změnu je třeba v této fázi prověřit a nalézt odpověď na otázku „je možné požadovanou Změnu v současném infrastrukturním prostředí realizovat?“. Odpověď by měla být ano/ne (RFC je chválena/odmítnuta) popřípadě RFC je schválena s určitou podmínkou, kterou je nutné ve stanovené lhůtě vyřešit. Např. v rámci projektu má být nasazena verze již nepodporované databázové aplikace. Instalace aktuální verze není možná (aplikace jí nepodporuje), ale stejně tak odklad Změny. Proto je stanovena podmínka následného přechodu na podporovanou verzi pomocí dodatečné Změny implementované v dohodnutém čase. Druhou podstatnou částí narážející na předchozí příklad je prověření řešení z pohledu interních standardů. Zaměření se na stávající standardy je první logická možnost, ale díky neustálému vývoji IT je důležité posoudit řešení i z pohledu do budoucna. Nerespektování tohoto faktu může například vést k implementaci řešení, u kterého se později ukáže, že končí jeho podpora u dodavatele, nebo může být implementováno řešení vyžadující unikátní infrastrukturu, s čímž jsou samozřejmě spojené vyšší náklady na její provoz. Následné řešení vzniklé situace je v každém případě drahé, ať už se jedná o speciální kontrakt na dodatečnou podporu nebo migraci na podporovanou verzi. Proto se zde uplatňuje snaha o maximální standardizaci popř. konsolidaci směrem k maximálnímu využití stávajícího prostředí a to jak HW tak SW. Navažme zde na předchozí příklad s tím rozdílem, že projekt nemůže splnit podmínku dodatečného přechodu na podporovanou verzi databázové aplikace. V tomto případě bude taková změna zamítnuta, jelikož by výsledné řešení bylo nepodporovatelé.

44

Nelze totiž převzít do provozu službu, pro kterou není oficiální podpora ze strany jejího dodavatele. Vlastním technickým prostředkem pro zajištění výše uvedené kontroly jsou IA/RA WO. Ty jsou vytvářeny v rámci daného RFC požadavku v HPSD. Tyto WO jsou přiřazeny jednotlivým skupinám (WG), které se této fáze účastní. Existuje tu určitá sada povinných WO, které jsou vytvářeny pokaždé a sada dodatečných WO, které jsou vytvářeny dle specifického rozsahu dané Změny. Obrázek 15. IA/RA workordery v HPSD

Zdroj: Vlastní tvorba (DHL HPSD)

Povinná sada WO: Capacity planning – reviduje platnost objednávky (Sales Order) a obsah cenové nabídky (předchází sestavení objednávky) pro daný projekt. Obsah nabídky je kontrolován oproti dokumentu Server Build Form (dále jako SBF). Jde o technický dokument popisující jednotlivé technické parametry požadovaných serverů (HW, SW, konfigurační parametry) – dle tohoto dokumentu je požadovaný server nainstalován. Platnost Sales Order je základní předpoklad, díky kterému je možné v případě nedostupnosti požadovaného HW na skladě zajistit jeho objednání, jelikož je zaručeno, že daný HW bude projektem zaplacen. Configuration management – kontroluje, zdali Změna bude vyžadovat aktualizaci Configuration Item (CI) v CMDB. Např. projekt přinášející novou službu si vyžaduje i vytvoření nové služby v CMDB. License management - reviduje požadavky na použitý SW uvedené v SBF a vlastním procesem spolu s projektovým manažerem potřebné licence zajistí. Operations support – se zaměřuje na technické parametry řešení a kontroluje je oproti firemním standardům stanoveným pro produkční prostředí. A dále na základě informace o

45

plánovaném uvedení služby do produkce (Release To Production, dále RTP) a počtu nových serverů předběžně zarezervují prostor pro provedení Operations Acceptance Testů (dále jako OAT) což je procedura vyžadovaná před RTP. Tomuto procesu je věnována část v kapitole 3.8 Týdenní cyklus RFC. Project leadera – jakožto budoucí koordinátor release Změn reviduje Změnu z projektového pohledu. To znamená prověření milníkových datumů, vyjasnění rozsahu Změny, dalších požadavků a zběžná kontrola ostatních IA/RA WOs pro lepší pochopení Změny a případných problémů, které bude nutné řešit. Commissioning services – je skupina, která provádí vlastní instalaci a základní konfiguraci serverů na základě SBF dokumentu. Proto se zaměřují na kontrolu SBF dokumentů a upřesnění všech nejasných nebo chybných požadavků tak, aby vlastní instalace byla maximálně plynulá. Příklad revidovaných parametrů: verze OS a SW, rozdělení disků, případná databázová a clusterová konfigurace, nastavení přístupů atd. Information Security – hlídá jakoukoliv odchylku od stanovených bezpečnostních standardů. Posuzovány jsou použité aplikace, formy přenosu dat a přístupy k datům. Zjišťuje se i citlivost dat v dané aplikaci, aby bylo možné nastavit adekvátní požadavky na bezpečnost, které musí projekt splnit. Release Management – stejně jako Capacity management reviduje projektovou cenovou nabídku, ale navíc ještě dohodu o placení provozu aplikace (run costs). Tato dohoda musí být odsouhlasená ještě před přípravou/instalací prostředí. Vlastník dané aplikace v okamžiku uvedení služby do provozu začíná platit za provoz aplikace na základě této dohody. Příklad dodatečných WO: HPUX, Windows, Linux – Dle použitých platforem jsou vytvořeny WO pro relevantní skupiny, které prověří, zdali požadované řešení je v souladu se stanoveným standardem pro danou platformu. GTS Engineering – prověřuje případný vliv na síťovou infrastrukturu. Dále určuje, zdali bude projekt povinen předložit a nechat si schválit Network Impact Analysis (NIA), detailní analýzu potřebné šířky pásma pro provoz aplikace ve vztahu k současným parametrům zatížení datové linky. Další WO se vytvářejí dle potřeby.

46

3.3.1 Workflow a rozdělení zodpovědností IA/RA fáze navazuje na předchozí Change initiation fázi. RFC je stále ve CM HPSD frontě, a CM bezprostředně po změně statusu RFC na Risk & Impact vytváří IA/RA schvalovací WO pro jednotlivé skupiny dle již zmíněných pravidel. Na základě těchto WOs jednotlivé skupiny Změnu revidují případně žádají requestora o doplnění, vyjasnění či opravení informací. Pro úspěšné zakončení této fáze je vyžadován souhlas od všech zúčastněných stran. Pokud je Změna zamítnuta - Rejected, CM informuje requestora o důvodech zamítnutí. Obrázek 16. IA/RA fáze

Zdroj: Vlastní tvorba

Zodpovědnosti Change Managementu: 

vytvoření Risk and Impact (IA/RA) WO pro všechny vyžadované skupiny,



pokud jsou všechny IA/RA WOs odsouhlaseny jednotlivými skupinami, Change analytik změní status Změny na „To be Approved in principle“ a Změna může postoupit do další fáze.

Zodpovědnosti requestora: 

monitorování IA/RA WO a v případě jakýchkoliv dotazů, problémů či komentářů promptně reagovat,1

1

IA/RA komise totiž může kontrolovat i ostatní IA/RA WOs. Případný návrh jiného řešení jednou skupinou může měnit rozsah Změny a tím pádem mít vliv na skupinu jinou (což v této fázi není příliš časté ani přímo vyžadované). Nebo se ostatní skupiny rády inspirují ve WO druhých a vyžadují obdobné záruky nebo řešení problému apod. Proto je v zájmu requestora tyto případné nesrovnalosti uvést co nejdříve na správou míru, aby nevznikaly mnohdy zbytečné dotazy a IA/RA fáze se neprotahovala.

47



aktualizace CAB Checklistu, pokud se ukáže, že uvedená informace není správná nebo postačující,



dohlížení na plnění stanovených konečných termínů (deadlines) pro schvalování jednotlivých IA/RA WO. V případě nulové reakce na WO je zodpovědností requestora kontaktovat patřičnou skupinu a zajistit nápravu.

Zodpovědnosti IA/RA skupiny: 

Revidovat RFC na základě poskytnutých informací v RFC a CAB Checklistu. V případě nesrovnalostí požadovat v IA/RA WO upřesnění. Pokud je požadované řešení nerealizovatelné - neschválení WO. Pokud je naopak řešení realizovatelné schválení v požadované časové lhůtě evidované u každého IA/RA WO.

3.4

Change Review & Approval

Vstup: Změna schválená IA/RA komisí (Impact & Risk analýza) Výstup: Změna schválená „In principle“ nebo zamítnutá Změna Typ změn: Release Statusy RFC v této fázi: To be approved in principle, Rejected V předchozí fázi došlo k odmítnutí nebo upravení nevyhovujících Změn tak, aby jejich implementace byla v podmínkách datového centra možná. Navazující fáze Change Review & Approval nebo To be Approved in principle (popř. CAB approval) má s předchozí fází mnoho společného, ovšem je zde jeden zásadní rozdíl. A tím je úroveň, na které schvalování in principle probíhá. IA/RA fáze je spíše technického charakteru, kdežto současná CAB fáze probíhá již o úroveň výše – na manažerské úrovni. Na této úrovni Změnu revidují jednotliví vedoucí příslušných oddělení (dále také CAB komise). Tato revize má u jednodušších nebo kvalitně připravených Změn spíše formální charakter a rozdíl oproti IA/RA není tolik patrný. U ostatních Změn, které však nelze automaticky chápat jako nekvalitně připravené, se může jednat o natolik komplikované podmínky tvorby připravovaného řešení, kdy technický specialista není osoba, která by měla rozhodovat o strategických záležitostech. Ostatně to ani není v jeho osobním zájmu. Proto do této fáze vstupují zmínění manažeři jednotlivých oddělení, kteří shrnují poznatky technických specialistů a do svého závěrečného rozhodnutí promítají zmíněné strategické podmínky.

48

Jednotliví členové CAB komise rovněž hájí zájmy svých oddělení, což má nejčastěji za následek dotazy ohledně budoucí podpory řešení v produkčním prostředí. Vlastní struktura podpory řešení spolu s rozdělením zodpovědností (1st, 2nd level, aplikační podpora apod.) se specifikuje v support model1 dokumentu. CAB komise reviduje parametry řešení oproti specifikovanému (requestorem v CAB Checklistu) druhu support modelu. Pokud budoucí řešení bude mít např. Standardní support model (řešení od HW až po aplikaci je podporováno pražským ITS centrem), musí být všechny parametry řešení souladu pražskými standardy2. CAB fáze se rovněž stává místem pro dořešení všech doposud zjištěných nedostatků a stanovení zajišťujících opatření jasně definující podmínky dalšího vývoje a následného RTP řešení. Souhlas CAB komise je však velmi důležitý milník startující další procesy jako je např. Commissioning proces, při kterém je požadovaný server nainstalován (dle již zmíněného SBF dokumentu), počínaje fyzickým umístěním až instalací do úrovně operačního systému3 konče. Z toho důvodu je vyžadována určitá pružnost CAB fáze, přičemž čekání na dořešení všech nalezených nedostatků toto kritérium rozhodně nesplňuje. Proto má člen CAB komise možnost udělit podmíněný souhlas - conditional approval, takže Změně není bráněno postoupit do další fáze, pokud je vyřešení nalezeného problému jen otázkou času. Podmíněný souhlas je zajištěn jasně definovanou a v RFC zaznamenanou podmínkou, kterou je nutné splnit většinou do konce následující fáze nebo jinak stanovené lhůty, jinak se podmíněný souhlas stává neplatným. CAB approval, stejně jako IA/RA approval, je technicky realizován pomocí WO. Schvalovací mechanismus je však rozdílný. CAB approval je jen jediný společný WO, v rámci kterého členové CAB komise virtuálně hlasují (ano/ne) popřípadě zveřejňují své komentáře a požadavky. CAB approval WO vytváří Change management bezprostředně po skončení IA/RA fáze. Pokud je CAB WO schválen celou CAB komisí, ale ve vlastním CAB WO se vyskytují připomínky nebo je udělen podmíněný souhlas, je povinností Change managementu vytvořit dodatečný WO CAB conditions, ve kterém budou tyto podmínky shrnuty. Tento WO bude přiřazen na requestora, který je povinen všechny tyto 1

Druhy support modelu: Standard, End to End(E2E), Hosting. Bez support modelu není možné RTP. CAB Checklist obsahuje odkaz na seznam aktuálních standardů na intranetu. Jendá se o matici různých druhů Operačních systémů, HW a middleware aplikací jasně definující co je pro danou platformu standardem. 3 Této fázi se říká ARE – Application Ready Environment. Server je připraven na instalaci a konfiguraci middleware aplikací 2

49

nedostatky odstranit. Takto je poměrně jednoduše zajištěna kontrola plnění podmíněných souhlasů. Obrázek 17. CAB Approval WO v HPSD

Zdroj: Vlastní tvorba (DHL HPSD)

Složení CAB komise: Manager of operations support – manažer zastřešující oddělení Operations Support, které představuje podporu databázových systémů, zálohování, monitorování a dále podporu Windows, Linux, Solaris systémů na úrovni 2nd level support. Jeho primárním zájmem je maximální standardizace řešení z důvodů optimální podpory řešení. Manager of operations delivery – manažer zastupující systémové administrátory a operátory držící neustálou podporu produkčních serverů na úrovni HW a operačního systému. Sleduje podobné zájmy jako OPS Support manager. Helpdesk – je většinou zastoupen team leaderem, který hájí zájmy helpdesku. Což je skupina poskytující first level support. Její primární zájem je maximální rychlost a efektivita řešení případných požadavků či incidentů. V případě nové služby musí být odpovědnosti jednoznačně definovány tak, aby bylo možné požadavky co nejrychleji směrovat na konkrétní a správné pracovníky podpory. Helpdesk kontroluje i budoucí parametry SLA. Např. pokud se bude jednat o kritickou službu s podporou 24x7, není možné, aby některá z částí řetězce podpory byla 8x5. Server services – představují vedoucí oddělení, jenž stanovují podnikové standardy pro platformy (Windows, HPUX, Linux). Jejich účast je volená na základě výskytu dané platformy v RFC. Obsahem jejich revize je kontrola dodržování stanovených standardů pro danou platformu. Manager of implementation – vedoucí oddělení skupiny Build and migration services, jenž zastřešuje organizační jednotku TI leaderů (Project leader). Jeho revize je zaměřena na celkový rozsah (požadavky) Změny, posouzení reálnosti dodržení požadovaných milníků (build řešení, OAT, RTP) a dalších projektových prerekvizit. Změna totiž v určité fázi přejde pod kontrolu právě TI leaderů.

50

Service owner – stávající nebo budoucí vlastník aplikace hájící primárně zájmy aplikace. Což je provoz aplikace dle stanoveného SLA a v případě RTP nové služby co možná nejhladší a nejrychlejší uvedení služby do produkce (minimální dopad na ostatní služby). Service owner zodpovídá za službu samotnému byznysu – většinou byznys IT jednotce (BUIT). V této fázi je v jeho zájmu jasné vymezení budoucích zodpovědností (Suport model, SLA) a maximální standardizace řešení z důvodu následné podpory. Hosting services – manažer zastřešující Hosting services oddělení. V těchto případech není přímo definován Service owner dané aplikace, jeho roli zastupuje Hosting manager, který komunikuje přímo s externím vlastníkem aplikace. Jeho zájmy jsou ve shodě se zájmy již popsané role Service owner s tím rozdílem, že Hosting manager nepodporuje danou aplikaci. Jeho role je nastavit a kontrolovat SLA parametry, které však končí na úrovni operačního systému. Aplikace je totiž podporována externě třetí stranou.

3.4.1 Workflow a rozdělení zodpovědností Obrázek 18. CAB (Approval in Principle) fáze

Zdroj: Vlastní tvorba

Zodpovědnosti Change Managementu: 

vytvoření CAB approval WO bezprostředně po skončení IA/RA fáze,



kontrola průběhu hlasování v rámci CAB WO,



uzavření CAB WO pokud všichni členové CAB komise vyslovili svůj souhlas, Změna statusu RFC na „Approved in principle“ a postup do další fáze procesu,

51



v případě vyskytujícího se podmíněného souhlasu nebo připomínek ze strany CAB komise vytvořit CAB conditions WO.

Zodpovědnosti Requestora: 

monitorování CAB WO, zejména průběhu hlasování. Pokud některý ze členů CAB komise neodpoví ve stanovené lhůtě, je sjednání nápravy primárně na requestorovi, sekundárně uplatňuje svou autoritu CM,



pokud se změní status CAB WO na Pending - čekání, requestor musí neprodleně vzniklý problém nebo dotaz vyřešit. Pokud problém vyřeší, je třeba popsat řešení do CAB WO a změnit status zpět na Assigned – přiřazeno.

Zodpovědnosti člena CAB komise (release RFC): 

ve stanovené lhůtě revidovat RFC. V případě nesrovnalostí požadovat upřesnění informací. V případě vážných nedostatků nebo nesplnitelných požadavků muže hlasovat záporně. Tím se celý hlasovací WO stává neúspěšným, nehledě na hlasování ostatních. Pokud jsou nedostatky spíše formální nebo se na řešení pracuje/bude pracovat, čili řešení je jen otázkou času, může člen CAB komise udělit podmíněný souhlas. V tom případě musí jasně specifikovat svou podmínku, včetně případného termínu, do CAB WO,



pokud je CAB WO ve stavu Pending, mají ostatní členové právo čekat se svým souhlasem do vyřešení problému, kvůli kterému byl stav WO změněn.

3.5

Create Change Package

Vstup: Změna schválená in principle (CAB approval) Výstup: Otestovaný a zdokumentovaný Změnový balíček odsouhlasený IQG komisí pro implementaci spolu s přiloženým implementačním RTP plánem Typ změn: Release, Routine Statusy Změny v této fázi: Approved in Principle, To be approved for Implementation, Build&Test, Tested Mohlo by se zdát, že předcházející fáze jsou z pohledu projektu poměrně dost byrokratické resp. zdlouhavé, zejména pokud by se diskutovala přidaná hodnota pro samotný projekt. U kvalitně připraveného projektu tomu tak z části je. Je však důležité si uvědomit, že předchozí fáze slouží jako určitá „ochrana“ datového centra před nestandardními nebo 52

nekvalitními Změnami, které by mohly narušit nastavené procesy, služby nebo IT infrastrukturu. Proto je nutné, aby byla požadovaná Změna důkladně analyzována. Je třeba znát přesné požadavky zákazníka/projektu a naopak zákazník musí znát přesné parametry řešení, které obdrží. Rovněž musí být zaručeno, že řešení, na kterém se bude dále pracovat, je realizovatelné1. Vstup do této rozsáhlé fáze je realizován souhlasem zmíněné CAB komise (pro release Změny) nebo Change managementu (pro routine Změny). Routine Změny díky své „jednoduchosti“ nebyly nuceny absolvovat předchozí fáze a po prvotní revizi Change managementem rovnou vstupují do této vývojové fáze. Vstupem do fáze Create Change package se spouštějí hlavní projektové aktivity. Požadované řešení - Změna - se začíná vyvíjet a následně se celá Změna začne připravovat na implementaci – RTP. Těmto aktivitám se souhrnně říká právě Create Change Package. Obsah samotného Change balíčku (package) je popsán dále v této kapitole.

3.5.1 Rozdělení zodpovědností V této fázi dochází rovněž k podstatnému rozdělení zodpovědností, jak už bylo nastíněno v kapitole Change initiation. Doposud ležela celková zodpovědnost za Změnu primárně na requestorovi. Parametr, který toto rozdělení z části určuje, je již zmíněný typ Změny. Do hry však vstupují i zmíněné parametry priorita a riziko. Obecně se dá říci, že hlavní odpovědnost za projekt stále leží na requestorovi, ale odpovědnost za hladký průběh přípravy požadovaného řešení a přechodu do produkčního prostředí (RTP), v případě release a některých routine Změn, leží na TI Leaderovi (proj. vedoucího operations oddělení). A v případě pre-authorised, minor a většiny routine RFC zůstává odpovědnost na Change managementu. Change analytik tak řídí přípravu implementace této Změny. Toto rozdělení zodpovědností není v ITIL nějak definováno, důvody proč tomu tak je, budou níže popsány. Zmíněné rozdělení shrnuje následující tabulka. Tabulka 7. Rozdělení zodpovědností Typ RFC

Priorita

Release Emergency Urgent High Medium Low

TIL

Routine

TIL / CM

Minor

Preauthorized

CM

Definováno v Request katalogu

Zdroj: Vlastní tvorba

1

Pokud se jedná o nový projekt či službu u které není zaručena funkčnost je nutné, aby projektu předcházel testovací projekt tzv. Proove of Concept (POC). Kdy se postaví minimální část požadovaného řešení nutná na otestování požadované funkčnosti.

53

3.5.2 Change package Je označení pro hotové a otestované řešení tzn. Změnu připravenou na implementaci. V HPSD se jedná o RFC, obsahující všechny potřebné dokumenty (např. plán technické implementace řešení - RTP plán, v případě nových serverů Reboot instrukce, Support model, Network Impact Analysis atd.) a v neposlední řadě všechny potřebné souhlasy potřebné pro implementaci Změny, které autor postupně dále popíše. Z důvodu lepší přehlednosti si rozdělme tuto fázi na dvě části :  Tvorba řešení a testování  Schválení implementace Následující řádky se budou primárně zabývat variantou Změny(release), která přináší novou službu(service) včetně nového HW. Z procesního hlediska se totiž jedná o nejsložitější kombinaci, na kterou se kromě všech částí Change management procesu vztahují resp. váží ještě další subprocesy, které budou rovněž popsány, jelikož jsou s Change management procesem těsně spjaty.

Tvorba řešení a testování Obecně by se dalo říci, že v této fázi se požadované řešení vyvíjí. Pod touto definicí si však nelze představit jen zmíněnou variantu, kdy se připravuje nový HW. Tato část je relevantní pro všechny varianty včetně Routine RFC, u kterých se může jednat „jen“ o podrobné testování a plánovaní implementace. V předchozí fázi již bylo zmíněno, že jakmile Změna získá souhlas CAB komise (Approval in principle), je možné spustit další podpůrné procesy. Jedním z těchto procesů je Commissioning proces představovaný Commissioning RFC1. Commissioning RFC je jednoúčelová, pre-autorizovaná Změna s jednoduchým workflow řídící instalaci a konfiguraci serveru až do úrovně instalace operačního systému (application ready environment). Poté již následuje instalace a konfigurace aplikací specifikovaných v SBF a server je předán projektu. Tato část přípravy řešení není v CM procesu nikterak zakotvena nebo spíše hlídána. Což by velmi jednoduše mohlo vést k dojmu, že po instalaci a doladění aplikací je řešení připraveno na přechod do produkčního prostředí. Ale právě díky tomu, že průběh instalačních a konfiguračních prací není v CM nikterak zakotven, což by z důvodu 1

Je RFC ve které je použito jednoduché workflow, které dle zvolené platformy stanovuje jednoduché workflow které začíná fyzická instalací serveru a končí instalace zvoleného operčního systému

54

rychlosti instalace ani nebylo úplně vhodné, je nutné, aby servery před tím než budou uvedeny do produkčního prostředí prošly celou řadou testů. První testy v režii projektu resp. skupiny budoucí aplikační podpory kontrolují, zdali řešení po aplikační stránce dělá to, co dělat má, a je možné jej podporovat. Tyto testy ze nazývají Technical Acceptance Tests (TAT). Dalšími testy, které jsou již v režii budoucích uživatelů služby, se zaměřují na výstup nové služby. Služba totiž může poskytovat na dané adrese potřebný report, což prověří TAT, ale tento report musí být to co, uživatel očekává. Tyto testy se nazývají User Acceptance Tests (UAT). TAT a UAT testy jsou prováděny i u Změn přinášejících novou funkcionalitu (i bez nového HW), která je tímto způsobem testována. Po úspěšném absolvování TAT a UAT je možné spustit další sérii testů Operations Acceptance Testing (OAT)1, což je prověření serverů zdali jsou nainstalovány dle stanovených standardů. Tento proces je řízen Operations oddělením a je plně zakotven v CM procesu, čili bez jeho úspěšného absolvování nelze převzít server do produkčního prostředí – nelze Změnu implementovat. OAT jsou řízeny pomocí speciálních WOs v rámci RFC v HPSD. Status WO popisuje stav OAT tesů což umožňuje přehlednější kontrolu. Obrázek 19. Příklad OAT WO v HPSD

Zdroj: Vlastní tvorba (DHL ITS)

Schválení implementace řešení - IQG Jakmile je dané řešení – Změna otestována a byznys rozhodne o implementaci Změny, je možné postoupit do druhé logické části. Tato závěrečná část Create Change Package fáze, je platná pro všechny release a routine Změny. Je to obdoba fáze IA/RA, zaměřená na revizi Změny z pohledu budoucí implementace. Hlavním cílem je, aby implementace Změny byla co nejlépe naplánovaná a případné problémy během implementace co nejlépe ošetřeny. Zjednodušeně se této fázi říká IQG – Implementation Quality Gate. IQG je další rozšíření, které ITIL přímo nepopisuje. Stěžejními dokumenty, které se v této fázi revidují, je IQG checklist a RTP plán, což jsou již zmíněné součásti hlavního dokumentu Změny 1

OAT – je proces při kterém Operations oddělení kontrolují celkové nastavení serveru včetně fyzické revize. Operations oddělení si tímto způsobem ověří, že server je postaven dle stanovených standardů a tím pádem je z jejich strany plně podporovatelný. Je tedy možné jej převzít do produkčního prostředí a zodpovídat za jeho provoz. TAT a UAT jsou vyžadovány před OAT, aby případné řešení nalezených problémů nezasahovalo do průběhu OAT a nebylo nutné OAT znovu opakovat.

55

CM Checklistu. IQG Checklist je obdobou CAB Checklistu a využívá i část otázek (včetně odpovědí) uvedených v CAB Checklistu tak, aby popis plánované implementace byl opět velmi dobře srozumitelný. Ostatní otázky se primárně zaměřují na konkrétní popis řešení, jeho budoucí přínosy, vliv na okolní infrastrukturu a služby, testování řešení před nasazením, následky v případě neúspěšné implementace, kroky pro obnovu narušených služeb atd. RTP plán je velmi specifický dokument, který kromě toho, že obsahuje přehled všech severů a služeb (viz. Tab. 8.) u kterých bude vyžadován výpadek (downtime), obsahuje plán vlastní implementace (viz. Tab. 9.). Tento plán je představován rozpisem jednotlivých kroků pro konkrétní skupiny pracovníků (WorkGroups - WG) včetně časového plánu a konkrétních instrukcí. RTP plán tak slouží nejen IQG komisi při revizi tím, že poskytuje jasný přehled, co se kdy na konkrétních serverech bude jakou skupinou dělat, ale také je to dokument, který se všechny zúčastněné skupiny po odsouhlasení patřičného IQG WO zavazují dodržet. Kromě implementačních kroků může RTP plán obsahovat ještě sadu před-implementačních kroků, které se zapisují stejně jako implementační. Jedná se však o přípravné nedestruktivní kroky, které se mohou provádět, aniž by Změna byla schválená IQG komisí. Např. o vytvoření adresářové struktury, připravení instalačních balíčku a další přípravné akce, které nemohou ohrozit provoz poskytovaných produkčních služeb. Z výše uvedeného je nyní jasné proč je tato část povinná pro všechen druh RFC. Bez RTP plánu není možné Změnu implementovat a to i v případě instalace „pouhého“ patche. Výjimku tvoří jen velmi jednoduché Změny implementované jednou skupinou pracovníků (viz. Tab 9. „Who (HP Service Desk Workgroup)“. U těchto Změn musí být popis implementace v IQG Checklistu natolik jasný a jednoznačný, že IQG komise nebude mít připomínek. Tabulka 8. Část RTP dokumentu specifikující impaktované CI Changed components and associated downtime Server Hostname(s) or CI name(s)

Downtime Service Name

Description/Note SERVER

SERVICE

1

czchols1509

SAP CAR - NW EP 7.0 PROD

no

no

PRODUCTION SAP Enterprise Portal

2

czchols1510

SAP CAR - BOBJ 3.1 PROD

no

no

PRODUCTION SAP Business Objects Data Services (BODS)

Zdroj: DHL ITS, vlastní úprava

56

Tabulka 9. Část RTP dokumentu Implementation Tasks If the proposed implementation date and time is outside standard Sunday change window provide business justification

I D

Server Hostname or CI name(s)

The change implementation takes longer than 1 day so exceeds the Sunday change window Start Time (PRG time)

Task

End Time (PRG time)

Additional comments/justificatio n

Who (HP Service Desk Workgroup)

Day 1 ITS Bulletin + e-mail sent (Start of RTP) 16:30

16:45

EMEA-SAP.COC.SUPPORT (SAP CAR Service Owner)

16:30

16:45

EMEA-SAP.COC.SUPPORT (BODS Technicians)

Make sure that SFTP script for countries of initial load is deactivated. No transfer of initially loaded data to ESB until verified by countries.

16:30

16:45

EMEA-SAP.COC.SUPPORT (Basis Technician)

Switch OFF OVO monitoring on BODS server (czchols1510) After executing this step, inform by email to David Kucera & Michal Plandor (EMEA-SAP.BASIS)

17:00

17:15

EMEA-SHIFT.SYSADMIN

1 2

3

4

czchols1510

czchols1513

czchols1510

Stop the running Deltas relevant to Repository 3

Zdroj: DHL ITS, vlastní úprava

RTP plán, IQG checklist a komunikační plán1 jsou povinné prerekvizity vyžadované před IQG schvalováním. Aktualizace této dokumentace je povinností requestora. TI leader nebo Change analytik následně vytvoří IQG WO pro jednotlivé skupiny účastnící se IQG schvalování. Jednotlivé skupiny primárně revidují „své“ kroky v RTP plánu, zejména jejich srozumitelnost, jednoznačnost a smysluplnost. Při vytváření IQG WO se opět uplatňuje určitá sada povinných WO a doplňkových WO. Povinné IQG WO: Operations delivery – skupina držící podporu 24x7 nad produkčními servery do úrovně operačního systému. Operations support – skupina držící podporu 24x7 nad databázemi, zálohováním a monitoringem serverů. Jedná se o 2nd level podporu (hlubší a komplexnější znalost). Tato skupina zajišťuje OAT testy. Pokud Změna vyžaduje OAT, které probíhají většinou týden před RTP, uděluje OPS Support svůj IQG souhlas až po úspěšném dokončení těchto testů. Security – hlídá případné bezpečnostní nedostatky jako např. sdílení a posílání hesel, zacházení s citlivými daty (např. manipulace s exportem databáze) apod. Service owner – vlastník dané služby, který se snaží, aby implementace dané Změny byla co nejméně riziková pro jeho službu, jelikož je za službu zodpovědný. V případě, že určitá služba není přímo předmětem RFC, ale může být implementací Změny negativně 1

Komunikační plan - obsahuje konkrétní role a kontakty na zúčastněné skupiny (oncall pro jednotlivé skupiny)

57

ovlivněna (mění se společné knihovny, interface, databáze atd.), má Service Owner této služby právo neschválit IQG WO a dožadovat se vyřešení problému, které zodpovědná osoba TIL/CM zajistí společně s requestorem.V krajním případě má tento SO právo zastavit přípravu implementace Změny. Implementační týmy – WO jsou vytvořeny pro všechny skupiny podílející se na RTP plánu (jejich skupina má přiřazeny některé kroky). Svým souhlasem potvrzují srozumitelnost přiřazených kroků a připravenost svého týmu k provedení požadované akce v daném čase. Doplňkové WO: GTS Engineering, Operations – IQG WO je vytvářen v případě uvedení nové služby do produkce, kde je potřeba posoudit vliv služby na zatížení sítě (počet připojených uživatelů, přenosy dat)1. Nebo v případě možného vlivu na zatížení sítě (např. přenos velkých objemů dat, zátěžové testy apod.). Hosting services – v případě uvedení hosting2 služby do provozu. Helpdesk – je vytvořen pouze v případě, kdy se objevila připomínka ze strany Helpdesku v CAB fázi. Helpdesku je tak dána možnost tuto připomínku před implementací zkontrolovat. Topaz – vytváří se v případech kdy RFC nějakým způsobem ovlivňuje Topaz3 nebo SiteScope4 monitoring. TIL nebo CM má právo na základě vlastního uvážení vytvořit další IQG WO a tím zajistit důkladnější revizi Změny. Business approval: Reprezentuje konečné schválení/přání byznysu implementovat Změnu pro danou službu. Zajištění zmíněného potvrzení je zodpovědností projektu, který si sám rozhoduje, kdy má být Změna implementována. Z tohoto pohledu by nemuselo být toto potvrzení přímo

1

NIA – Network Impact Analysis, je dokument revidující nároky aplikace na velikost přenášených dat zpracovávaný GTS oddělením. NIA dokument může být: schválen – implementace je možná, schválen s připomínkami – ty je nutné před implementací odstranit, neschválen – aplikace by vytěžovala datovou linku nad únosnou mez, provoz ostatních aplikací na dané lince by byl narušen 2 Hosting je druh podpory kdy datové centrum podporuje dané řešení jen do úrovně operačního systému. Aplikační podpora je tedy mimo datové centrum. Hosting serv. astupují zájmy. 3 Topaz je speciální způsob monitorování aplikací umožňující naskriptování určitých kroků umožňující detailní testování funkčnosti aplikace 4 SiteScope je způsob monitorování Hostingových služeb, testující jen dostupnost daného serveru

58

vyžadováno. Zkušenost z praxe ale ukazuje, že toto potvrzení by mělo být dodáno co možná nejdříve, jelikož mnoho projektů řeší UAT na poslední chvíli a dosti často se stává, že je UAT neúspěšné. V tom případě se implementace Změny odkládá a IQG hlasování je nutné v budoucnu znovu opakovat. Pokud byl již některý WO schválen, znamená to, že vynaložená práce na revizi přišla vniveč. Globální approval: Je speciální souhlas, jenž se uplatňuje v případě implementace Změny s globálním rozsahem. Což znamená, že aplikační podpora, HW nebo uživatelé jsou z více než z jednoho regionu. Tato forma schválení je nutná z důvodu existence dalšího datového centra v APIS, které je tímto způsobem zapojeno do procesu a podílí se tak na revizi Změny. Globální IQG WO je vytvářen jako WO v daném RFC požadavku v HPSD. Na základě tohoto WO je zajištěn Change managementem v APIS potřebný souhlas od vlastníka tamní aplikace nebo jednotlivých skupin zapojených do implementace. IQG Board approval: Formální částí, která uzavírá celý proces schvalování IQG workorderů (WO), je IQG meeting. Jedná se o výbor zástupců jednotlivých oddělení a pozvaných zástupců jednotlivých Změn (pokud si to okolnosti žádají), který prochází seznam RFCs pro daný týden - agendu a zajišťuje tak poslední kontrolu Změn před jejich implementací. Tato kontrola vychází především z obsahu jednotlivých IQG WO, jenž mohou obsahovat různé komentáře nebo připomínky. Dále je zde kontrolováno, zdali requestor splnil všechny podmínky stanovené v CAB fázi, jež jsou shrnuty v CAB conditions WO. Support model je v případě Změny přinášející novou službu dalším bodem, který je zde kontrolován. Přičemž se nejedná se o revizi samotného dokumentu, ale o to, zdali byl schválen všemi stranami podílející se na podpoře služby. Pokud IQG komise nalezne nedostatky formálního charakteru, může udělit podmíněný IQG souhlas, který tak formou jasně specifikované podmínky poskytuje určitý čas na jejich odstranění. Pokud jsou však nedostatky zásadního charakteru a jejich odstranění si vyžaduje podstatně více času a úsilí, je Změna na IQG meetingu zamítnuta a není možné jí daný týden implementovat.

59

Obrázek 20. Příklad IQG WO v HPSD

Zdroj: Vlastní tvorba (DHL HPSD)

Schvalovací matice V předchozích kapitolách byla zmíněna většina potřebných souhlasů, které musí Změna před svojí implementací získat. Následující tabulka všechny tyto souhlasy přehledně shrnuje v závislosti na prioritě Změny. V tabulce je vidět, že v jednom řádku “Typ RFC“ vystupují release, routine a minor, pre-authorised, což jsou na první pohled různé kategorie Změn. Důvodem proto je jednak zmíněné rozdělení zodpovědností v Tab. 7. na str. 53, které vychází z běžné praxe, a za druhé fakt, že na první pohled chybějící kategorie major a significant jsou sice rozdílné, ale z pohledu CM procesu zde žádný rozdíl není a procházejí stejným procesem. Velmi zjednodušeně by bylo možné napsat release=major a routine=significant, což by však bylo je částečně pravdivé.

Priorita

Tabulka 10. Schvalovací matice Emergency Urgent High Medium Low

Release SM + Urgent CAB + EC SM + Urgent CAB + IQG

Typ RFC Routine SM + EC SM + IQG nebo EC

SM + CAB + IQG

SM + IQG

Minor

Preauthorized

CM

Definováno v Request katalogu

Zdroj: Vlastní tvorba

SM (Senior Manager) - Jedná se o Senior Managera requestora . Uděluje úvodní Approval to Initiate – souhlas pro zahájení prací na Změně . Urgent CAB (Approval in Principle) - Představuje zrychlenou variantu CAB souhlasu, který v tomto případě uděluje pouze Change manager. Viz. Kapitola 3.9. EC (Emergency Committee) - Komise udělující finální souhlas Approval to Implement, který je potřebný pro implementaci Změny Viz. Kapitola 3.9. 60

CAB (Approval in Principle) - Schválení Změny, jenž spouští proces vytváření a přípravy Změny. (součástí je i IA/RA fáze). IQG (Approval to Implement) - Výše uvedený souhlas IQG komise umožňující postoupení do další fáze CM procesu Implement Change – implementaci Změny. CM (Change Manager) - Schvaluje Změnu pro implementaci - Approval to Implement.

3.5.3 Workflow a rozdělení zodpovědností Obrázek 21. Create change package fáze

Zdroj: Vlastní tvorba

Po obdržení schválení In principle, celou dobu vývoje a testování řešení má RFC status Build&test. Pokud RFC získá všechny vyžadované IQG souhlasy včetně finálního souhlasu IQG komise a samotný projekt obdrží schválení od byznysu, mění se status na Tested a Změna je přiřazena TILem do Change management HPSD fronty (pokud tam již není tzn. je celá řízena CM). CM dále připraví RFC na implementaci vytvořením implementačních WO. Ty jsou vytvářeny na jednotlivé skupiny podílející se na RTP plánu. Jakmile jsou WO vytvořeny, RFC opět mění status a to na Approved for Implementation. S tímto statusem přechází Změna do Implementační fáze. Zodpovědnosti Change Managementu: 

v případě Změny s globálním dopadem - zajištění IQG souhlasu od datového centra v APIS,

61



příprava IQG agendy (seznamu RFC pro IQG meeting pro daný týden),



vedení IQG meetingu a následná distribuce IQG agendy (závěry IQG komise),



vytvoření implementačních WO, pokud je Změna plně schválena,



zajištění schválení a přípravy implementace pre-authorised, minor a jednodušších routine RFCs,



posouzení nových požadavků requestora a navržení následných opatření (např. requestor bude požadovat postavení a RTP dodatečného serveru. Což ale není obsaženo v původním rozsahu Změny. Proto CM zajistí přeschválení/prověření nového rozsahu Změny CAB komisí1.

Zodpovědnosti requestora: 

pracovat na vývoji řešení dle projektového plánu a odsouhlaseného rozsahu Změny,



v případě změny odsouhlaseného rozsahu (scope) Změny definované v CAB checklistu neprodleně kontaktovat Change management,



příprava dokumentace pro získání IQG approval,



spolupráce s TI Leaderem nebo Change analytikem, aby byla zajištěna připravenost RFC na IQG approval v co možná nejvyšší kvalitě a požadovaném čase,



kontrola IQG agendy po jejím obdržení a ověření, že RFC byla schválena popřípadě neprodleně vyřešit dodatečné připomínky - podmínky stanovené IQG komisí.

Zodpovědnosti TI leadera: 

dohlížení na vývoj daného řešení, vedení a naplánování implementace Změny, které získaly status Approved in principle (significant, urgent, emergency),



spolupráce s requestorem na vývoji řešení (reportování stavu, kontrola požadavků a jejich korekce v případě nesplňování stanovených časů či standardů),



dohlížení na pre-approved podřízené Změny nebo procesy (např. commissioning, NIA, privileged access requests),

1

V praxi se tak děje pomocí emailového upozornění kde je popsání nový rozsahu Změny. Jednotliví členové CAB komise mají možnost v případě větších pochybností požádat o nové CAB hlasování. Pokud tak neučiní ve stanovené lhůté nový rozsah je považován za odsouhlasený a Změna tak není zbytečně zdržována.

62



Vytváření podřízených Změn (např.Změna na vytvoření SQL instance na SQL farmě),



řízení a koordinace technických zdrojů pracujících na projektu (včetně řešení konfliktů) - Central point of contact pro všechny zúčastněné strany (datového centra) na projektu,



příprava RFC na konečné schválení IQG komisí – vytváření IQG WO, kontrola stavu a řešení případných problémů,



kontrola projektové dokumentace (CAB, IQG checklist, RTP plán, Server build form - SBF, reboot instrukce atd.),



plánování, řízení a koordinace zdrojů na procesu Operations Acceptance Testing – OAT včetně koordinace odstraňování nalezených nedostatků,



v případě Emergency Změny, seznámení se technickým pozadím RFC a důvody ,které vyžadují implementaci pomocí emergency procesu, zajištění kompletního schválení a konečného schválení Change managementem.

3.6

Implement Change

Vstup: Připravený, otestovaný a zdokumentovaný Změnový balíček odsouhlasený IQG komisí pro implementaci spolu s přiloženým RTP plánem Výstup: Implementovaná Změna Statusy Změny v této fázi: Approved for Implementation (schválená), Rejected (odmítnutá) Fáze Implement Change začíná bezprostředně po vytvoření implementačních WO Change managementem a změně statusu Změny na Approved for Implementation. V tuto chvíli již tedy existují všechny potřebné implementační WO pro všechny skupiny participující na RTP procesu - implementaci. Každá skupina má jeden WO zastřešující všechny zmíněné kroky v RTP plánu. Hlavním dokumentem pro tuto fázi je odsouhlasený RTP plán dle kterého jednotlivé skupiny budou postupovat. RTP plán je strukturován chronologicky, popisuje jednotlivé kroky včetně časů a detailů potřebných pro implementaci. V této části CM procesu se objevuje i nová role RTP koordinátor. Tato osoba je zodpovědná za řešení případných problémů, které mohou při implementaci nastat. Je tedy důležité, aby to byla osoba ideálně z projektového týmu (může být i samotný PM). 63

Většinou to nebývá přímo technik, jelikož je vyžadován určitý přehled i nad činností ostatních oddělení. Tato osoba je po dobu implementace central point of contact pro všechny implementační týmy. V případě vzniků problémů nebo zpoždění koordinuje a informuje ostatní týmy tak, aby byly posunuty následující kroky. Nebo naopak, pokud jde implementace nadmíru dobře a podaří se zredukovat případné časové rezervy na minimum, RTP koordinátor může kontaktovat všechny týmy a zajistit dřívější dokončení implementace než je plánováno. RTP koordinátor dále zajišťuje koordinaci 3rd 1party týmů a komunikuje se zástupci byznysu.

3.6.1 Workflow a rozdělení zodpovědností Obrázek 22. Implement change fáze

Zdroj: Vlastní tvorba

Zodpovědnosti RTP koordinátora: 

Zajištění, že všechny kroky budou provedeny tak, jak jsou naplánovány v RTP plánu včetně dodržení stanoveného časového plánu,



Zajistí, že implementační WO budou obsahovat informaci o průběhu či konci implementace,

1

3rd party – jsou externí (mimo DHL) týmy, konzultanti, dodavatelé atd.

64



Organizace a vedení GO / NO GO1 virtuálních meetingů rozhodujících o finálním uvedení do živého provozu nebo navrácení do původního stavu před implementací.

V případě neúspěšné implementace Změny je zodpovědností RTP koordinátora, requestora, Change managera: 1. Revidovat důvody a následky neúspěšné implementace, 2. Vytvořit případný požadavek na kontrolu integrity CMDB, 3. Zaznamenat v RFC všechny učiněné aktivity za účelem odstranění chyby, 4. Provedení Rollback/Back-out plánu – tj.uvedení prostředí do původního stavu před implementací.

3.7

Review Change and Close

Vstup: Implementovaná Změna (change package) Výstup: Post implementation review (PIR) – Uzavření RFC Statusy Změny v této fázi: Implemented, Failed, Closed Poslední formální částí Change management procesu je Review Change and Close fáze. Tato část CM procesu slouží k oficiálnímu vyhodnocení implementace a uzavření Změny. Change Management po implementaci Změny provádí tzv. Post Implementation review (PIR). V rámci této revize projde všechny implementační WO pro případné chyby nebo poznámky týkající se implementace a zároveň pošle emailem dotaz requestorovi, ve kterém ho žádá o zhodnocení implementace. Requestor má na své vyjádření týden, pokud v této lhůtě neodpoví, je Změna považována za úspěšně implementovanou a je uzavřena. V ojedinělých případech není možné v dané lhůtě implementaci zhodnotit, proto je možné si délku PIR dohodnout. U rozsáhlých migrací bývá z důvodu hypercare2 periody tato lhůta většinou měsíc. Při hodnocení úspěšnosti nebo neúspěšnosti se používají metriky, kterými lze rozhodnout, zdali implementace byla úspěšná či nikoliv. V praxi však většinou rozhoduje sám

1

GO/NO GO – je velmi důležitý implementační milník, kdy je většinou s byznysem potažmo uživatelem ověřena funkcionalita implementovaného řešení a je rozhodnuto, zdali je možné implementaci dokončit či nikoliv. 2 Stanovené období následující po implementaci, kdy jsou případné požadavky neprodleně implementovány. Po tomto období již musí všechny požadavky procházet Change management procesem.

65

requestor popřípadě se uplatňuje společný dialog zúčastněných stran, kde hlavní metrikou je „povedlo se/nepovedlo“ s tím, že konečné rozhodnutí je vždy na Change managerovi.

3.7.1 Workflow a rozdělení zodpovědností Obrázek 23. Review change and close fáze

Zdroj: Vlastní tvorba

Zodpovědnosti requestora: 

Zhodnotit postup implementace v Post Implementation WO. Toho hodnocení má zahrnovat i informaci o spokojenosti zákazníka spolu se zhodnocením průběhu implementace řešení.

Zodpovědnosti Change managementu: 

Vytvoření postimplementačního WO. V dané lhůtě vyhodnotit RFC na základě poskytnutých informací a uzavření post implementačního WO,



3.8

Zavření RFC, status je změněn na Closed (RFC je dále archivována v HPSD).

Týdenní cyklus zpracování Změn

V předchozích kapitolách autor popsal, jaké má Change management fáze, jejich podstatu, vstupy, výstupy a návaznosti. Avšak pro celkové pochopení výše uvedeného je třeba popsat, jak jsou jednotlivé části zasazeny do „běžného“ pracovního rámce organizace.

66

Z dosavadních informací je jasné, že implementace jednotlivých Změn se neděje nahodile, ale dle určitého řádu. Tento řád představuje implementování Změn založený na týdenní bázi. V tomto modelu není z Change management pohledu důležité, jak dlouho RFC získává potřebné schválení nebo jak dlouho se vytváří požadované řešení. Tento parametr je čistě individuální a odvíjí se od složitosti a kvality řízení projektu potažmo Změny. Tento týdenní model se zaměřuje čistě na implementaci a příbuzné aktivity. Na následujícím obrázku je vidět rozfázování jednoho týdenního cyklu po dnech, všechny zúčastněné role a jejich aktivity. Obrázek 24. Týdenní cyklus zpracování Změn IQG meeting

Vývoj a příprava řešení (TAT,UAT)

SO

NE

PO

ÚT

ST

RTP plán IQG checklist Reboot intrukce

PÁ

IQG minutes

SO

NE

Vytvoření implement. WOs

RTP meeting Vytvoření IQG WO

Implementer

Implementační Manager

ČT

Splnění IQG podmínek

Change analyst

Requestor

PÁ

Implementace

OPS

OAT

Zdroj: Vlastní tvorba

Pokud se blíže zaměříme na samotný týdenní schvalovací a implementační cyklus, je vidět, že hotové řešení, ať už v podobě release nebo routine, musí být připraveno do pátku předchozího týdne implementace a to včetně potřebné dokumentace. Touto dokumentací je: IQG checklist, RTP plán a Communication plán. Následně pak v pondělí TIL nebo Change analytik vytvoří IQG WO dle již zmíněných pravidel na relevantní HPSD skupiny. Tyto HPSD WO mají nastaven deadline dva dny. V této lhůtě mají všechny zúčastněné strany povinnost revidovat RFC v HPSD včetně dokumentace a případě jí v rámci IQG WO připomínkovat. Ve středu je již valná část WO schválena. V tento den je rovněž pravidelné setkání CM a TI leaderů (RTP meeting), kteří CM prezentují Změny pro daný týden. Dále jsou zde diskutovány a řešeny případné konflikty Změn, podmíněné souhlasy a další organizační záležitosti. CM dle výstupů z tohoto meetingu připraví IQG agendu, což

67

je kompletní seznam (včetně Změn řízených CM), jenž bude prezentován/revidován na IQG meetingu, který se následně koná ve čtvrtek. IQG komise zde prochází daný seznam a ke každé Změně se vyjádří, zdali je možné ji implementovat či nikoliv. Pokud je u Změny žádán podmíněný souhlas (např. některý z IQG WO ještě není v den IQG meetingu schválen nebo OAT nejsou dokončena), komise posoudí zdali, je možné tento podmíněný souhlas udělit či nikoliv. Vyjádření je poté zapsáno do IQG agendy, kterou následně CM distribuuje všem zúčastněným stranám. Plně schválené Změny (všechny IQG WO + souhlas IQG komise) jsou poté přiřazeny do CM HPSD fronty, kde je Change analytik pomocí implementačních WO připraví na implementaci. Změny s uděleným podmíněným souhlasem musí být ve dané lhůtě vyřešeny a rovněž přiřazeny do CM HPSD fronty. V případě překročení stanovené lhůty pro vyřešení CM zamítne implementaci těchto změn. Neděle je primárním (oficiálním) dnem vyhrazeným pro samotnou implementaci. Na tento den má většina provozovaných služeb vyhrazený prostor pro údržbu/Změny tzv. standard maintenance window/downtime window1. V tento den tak neprobíhají jen samotné implementace Změn, ale také standardní údržba systémů ze strany jednotlivých vlastníků služeb (Service owner) a systémových administrátorů. Neděle však nemusí být vždy nejvhodnějším dnem pro danou službu, proto existují určité výjimky. Seznam těchto výjimek je pevně daný a případná výjimka je specifikována v RTP plánu (viz. Tab 9. Str. 57) a kontrolována v IQG fázi. Jelikož se jedná o stále se opakující cyklus tak na pozadí výše zmíněných aktivit probíhají všechny další části CM procesu. Nové Změny jsou revidovány a schvalovány (IA/RA, CAB), vyvíjeny a přiřazovány zodpovědným pracovníkům.

3.9

Urgent a Emergency proces

V teoretické části popisující Change management proces dle ITIL, zmínil autor poprvé speciální kategorii urgentních Změn, která si vyžaduje speciální pozornost. V následující třetí kapitole věnované již konkrétně DHL Change management procesu, byla kromě uvedené kategorie zmíněna i nová kategorie – emergency2. Cílem této kapitoly je popis těchto dvou speciálních kategorií, důvodů speciálního zacházení a v neposlední řadě samotný proces kterým procházejí.

1 2

Downtime window je podstatný parametr služby zaznamenaný v support modelu a SLA. Emergency je označení využívané ve firmě DHL ITS pro urgentní změny tak jak je definuje ITIL V2

68

Zaměřme se nyní na to, jak se tyto dvě kategorie klasifikují resp. jakým způsobem tento druh Změn vzniká. Obě kategorie se vyznačují tím, že je požadována jejich neprodlená popř. velmi urgentní implementace. Což by v případě aplikace “základního“ Change management procesu z časových důvodů nebylo možné splnit. Emergency je kategorie Změn s nejvyšší možnou prioritou. Jedná se o neplánované Změny u kterých je vyžadována bezodkladná implementace. Důvody pro to mohou být jednak preventivní, aby se zabránilo případnému dopadu na poskytované služby nebo je emergency Změna již důsledek nějakého incidentu, který omezuje nebo znemožňuje zákazníkovi využívat poskytované služby. Požadovaná implementace

Změny má

neprodleně tento stav napravit (např. výměna chybného HW nebo instalace opravného SW balíčku). Existuje však ještě jedna možnost „vzniku“ emergency Změny. Pokud z časových důvodů již není možné Změnu schválit na pravidelném čtvrtečním IQG meetingu a implementaci Změny nelze odložit na další týden, zbývá jediná možnost: schválení Změny emergency komisí, která tak nahradí potřebný IQG souhlas. Důvod vzniku takových změn jsou v současné době z větší části špatné plánování. Označení urgentních změn je v podání DHL ITS rozdílné oproti označení v ITIL V2. Urgentní Změny jsou definovány jako Změny vyžadující zrychlený CAB souhlas, který za normálních okolností trvá 5 dní (2 dny IA/RA fáze a 3 dny CAB hlasování). Tento typ Změn tedy není přímo spjat s výpadkem nějaké služby. Důvody pro to může být naléhavost na následné vytvoření Změny - build řešení (jak již bylo řečeno souhlas CAB komise spouští další aktivity) nebo je vyžadována nejbližší možná implementace. Což např. znamená, že Změna byla requestorem předána Change managementu v pondělí, ale implementace je vyžadována již ten samý týden někdy po čtvrtečním IQG meetingu. Standardní schvalování takové Změny CAB komisí a následné schválení IQG komisí nelze za tři dny stihnout. Proto Change management zajistí schválení Změny pomocí emailu na který musí členové CAB komise odpovědět do 2 hodin. Jakmile je Změna schválená CAB komisí a je dostatek času na schválení Změny na čtvrtečním IQG meetingu je opět možné následovat „základní“ CM proces. Pokud je již pozdě tzn. je již po čtvrtečním IQG meetingu, jediný způsob schválení Změny na implementaci je pomocí zmíněné klasifikace Změny na emergency a schválení emergency komisí. Příčiny vzniku urgentních změn je špatného plánování a nebo jsou výsledkem snahy vyhovět zákaznickému požadavku, který přišel na poslední chvíli.

69

Tabulka 11. Popis emergency a urgent procesů Části CM procesu Create Change Request

Change Initiation

IA/RA fáze Change Review and Approval (CAB)

Create Change Package Schválení implementace Změny – IQG WO Schválení IQG komisí (Approval to Implement)

Implementace Změny Vyhodnocení a uzavření Změny

EMERGENCY

URGENT

Requestor vytvoří RFC a vyplní Emergency / Urgent IQG checklist. Requestor dále opatří souhlas a vysvětlení naléhavosti Změny od svého nadřízeného a vlastníka služby (SO)

Requestor vytvoří RFC a vyplní Emergency / Urgent IQG checklist. Requestor dále opatří souhlas a vysvětlení naléhavosti Změny od svého nadřízeného, vlastníka služby (SO) a Professional Services Domain manažera Pokud se jedná o velmi naléhavou Změnu, potřebná dokumentace může být dodána zpětně do 24 hodin po implementaci Change manager zkontroluje vysvětlení naléhavosti a potřebné souhlasy. Dále určí a kontaktuje členy Urgent CAB komise Neaplikuje se Urgentní souhlas CAB komise (CAB approval) je zajištěn Change managementem pomocí emailu. Pouze Change manager nebo jeho zástupcem je oprávněn zahájit tento proces . Není rozdíl

Pokud se jedná o velmi naléhavou Změnu, potřebná dokumentace může být dodána zpětně do 24 hodin po implementaci Change manager zkontroluje vysvětlení naléhavosti a potřebné souhlasy. Dále určí a kontaktuje členy Emergency CAB komise Neaplikuje se Neaplikuje se

Není rozdíl Requestor musí sám proaktivně kontaktovat skupiny schvalující IQG workordery. Change Manager schvaluje Minor Emergency Změny Emergency komise (EC) schvaluje Significant nebo Major Emergency Změny

Není rozdíl Emergency Změny odsouhlasené Change Managerem a EC jsou prezentovány na následujícím IQG meetingu Zdroj: Vlastní tvorba

70

Requestor musí sám proaktivně kontaktovat skupiny schvalující IQG workordery. Change Manager schvaluje Minor urgentní Změny IQG schvaluje Significant nebo Major urgentní Změny pokud je dostatek času pro prezentaci Změny na IQG meetingu Emergency komise (EC) schvaluje Significant nebo Major urgentní Změny pokud není možno schválit na IQG meetingu Není rozdíl Není rozdíl

4 Nedostatky implementace 4.1

Co je implementováno podle ITIL

Change management byl v datovém centru DHL ITS implementován již při vzniku tohoto centra a od první migrace byly Změny na jednotlivých službách prováděny pod kontrolou Change management procesu s využitím zkušeností a samotného procesu z bývalého datového centra Magna v Londýně. Každé ze tří do loňského roku existujících světových datových center DHL ovšem mělo implementováno svůj vlastní interní Change management proces, který se lišil jeden od druhého. Společným pojítkem byl HP Service Desk jako jediný globální nástroj pro všechny ITIL Service Support procesy (Incident-Problem-Change and Konfigurační management). Globální Změny, tedy Změny ovlivňující prostředí (infrastrukturu, support nebo byznys) ve více světových regionech, byly schvalovány separátně ve všech jednotlivých entitách (EMEA, APIS a AMIS Change management skupinami) a příprava Globálních Změn musela být v souladu s individuálními pravidly platných pro jednotlivé entity. Tak například Změna, která byla zpracovávána EMEA Change management skupinou, ovšem na jejíž implementaci se buď podíleli pracovníci z AMIS regionu anebo servis běžel na infrastruktuře instalované v US anebo servis byl využíván byznysem s US, musela mít Změna vygenerovány všechny implementační WO včetně přiřazení dotyčné SD skupiny a konkrétní definice času pro implementaci. Pouze za splnění tohoto předpokladu se AMIS CM skupina začala dotyčnou Změnou zabývat a zahájila proces jejího schvalování. Tento přístup se lišil od EMEA CM skupiny, která pro Změny, týkající se pouze EMEA regionu, generovala implementační WO teprve po schválení implementace CABem, který zasedal v týdenních intervalech a schvaloval Změny k implementaci na následující víkend, popřípadě týden. Popsaný rozdíl v přístupu dokazuje, že CM proces nebyl globální a společný pro všechny regiony. K pokusu o sjednocení pravidel došlo přibližně před dvěma roky a Change management skupina společně s týmem Technické Implementace, jejímž členem je i autor, připravily tzv. Globální CM proces. Jeho hlavním přínosem bylo schvalování Změn „In principle“ (CAB) v okamžiku, kdy byznys IT rozhodl o tom, že bude sponzorovat daný projekt a akceptoval nabídku připravenou Bid managementem. Tím se jednotlivé skupiny Operations (Shift manažeři, Delivery manažer, Ops Support manažer, Telecoms manažer, 71

Security manažer a ostatní členové CABu) měli příležitost seznámit s tím, co je v datovém centru požadováno implementovat, a byla jim dána možnost vydefinovat podmínky, které bude nutné pro úspěšnou implementaci projektu splnit během přípravné fáze. Tyto podmínky se mohly týkat ICT infrastruktury, procesu, SLM, monitorovacích nástrojů apod. CAB jako schvalovací orgán začal v tomto okamžiku a dodnes funguje virtuálně díky používání HPSD (HP Service Desk). To dává jednotlivým členům CABu možnost si důkladně prostudovat vstupní dokumentaci a věnovat vlastnímu schválení takový čas, který si daný projekt svým rozsahem zasluhuje. CM proces dává každému na výše popsanou revizi dva pracovní dny. Dřívější pojetí CABu, který ITIL definuje jako Change manager review, se transformovalo pouze v IQG meeting, na které se probírá a finálně schvaluje seznam Změn pro daný týden - FSC (Forward Schedule of Changes). Vzhledem k tomu, že na implementaci jednotlivých Změn participují kapacitně omezené skupiny Service Delivery, Operations, Security, Solution support a Telecoms, je schválení FSC při fyzické účasti všech relevantních Operations složek nenahraditelné. Zastavme se u prvních schvalovacích koleček pro jednu individuální Změnu. Poté, co CM projde základní a povinnou dokumentaci, což je první filtrace, jsou vygenerovány IA/RA (Impact Analyses and Risk Assesment) WO pro všechny zúčastněné skupiny. Jejich zástupci se vyjádří k předložené Změně buď takovým způsobem, že ji bezpodmínečně akceptují, anebo vydefinují podmínky implementace, případně přijdou s doplňujícími dotazy k této Změně. Jakmile je vše vysvětleno requestor akceptuje vydefinované podmínky, začíná další kolo schvalování, tentokrát CABem. Výhodou je virtuální hlasování neboli „voting“ v rámci HPSD, na druhé straně nevýhodou je přiřazení hlasovacího práva v HPSD pouze konkrétní osobě bez možnosti delegovat zástupce. Takže pokud osoba delegovaná pro hlasování není z jakéhokoli důvodu přítomna nebo nemá přístup k HPSD, hlasování se nekoná a nikdo se nedozví proč. CM ovšem provádí pravidelně manuální kontrolu a teprve po pozitivním hlasování všech delegátů prohlásí Změnu za schválenou „In principle“. Tím se uzavře de facto třetí filtr a Změna může postoupit do fáze „In build“. V rámci implementace CM procesu jsou v DHL vydefinovány takové typy Změn, které nemusí procházet všemi třemi výše popsanými stupni schvalování. Těch je ovšem ve finálním počtu menšina. Bohužel na druhé straně většina Změn vstupuje do CM procesu teprve v okamžiku, kdy je Změna de facto po technické stránce připravena k implementaci. V takovémto nezřídka se vyskytujícím případě pak na výše popsané schvalování bezodkladně navazuje schvalování další,

72

tentokrát schvalování vlastní implementace, tedy RTP plánu (Release to Production Plan). V týdnu před vlastní implementací jsou nejdříve vygenerovány IQG WO (Implementation Quality Gate) a po jejich schválení dojde k finálnímu schvalování implementace na fyzickém IQG meetingu. Tím dochází v praxi velice často k situaci, že všechny úrovně výše popsaného schvalovacího cyklu je třeba zvládnout pro velký počet Změn během přibližně dvou týdnů. Pověřená osoba, mnohdy jedna a táž, se pak díky tomuto procesu vyjadřuje k jedné Změně čtyřikrát. Pokud vezmeme v úvahu, kolik lidí se na schvalování podílí, stává se pracnost vynaložená díky CM procesu nezanedbatelnou složkou celkové pracnosti přípravy a implementace každé Změny a přepychem společnosti, která si může dovolit vynakládat nezanedbatelné zdroje tímto směrem. Pokud se vrátíme k základním principům ITILu, zaměřeným k efektivitě procesů, docházíme v této situaci k viditelnému sporu. To, že schvalování si žádá spoustu času, se odráží i ve skutečnosti, že ke čtvrtečnímu IQG meetingu všechny delegované skupiny nestihnou některé Změny revidovat a akceptovat a tedy i čtvrteční IQG komise může pouze podmíněně schválit plánovanou implementaci, protože je nutno formálně dokončit kolečko akceptačních IQG WO. Pokud se na situaci podíváme z hlediska BUIT (Business Unit IT), která potřebuje implementovat Změny přirozeně co nejdříve po nalezení řešení konkrétního problému, pak minimální dvou týdenní schvalovací kolečko interní ITS organizace neprojevuje otevřenou orientaci na zákazníka, o kterou by mělo jít podle ITILu především. Pokud se zastavíme ještě i u IQG workorderů, pro všechny Změny je definována jejich implicitní skupina, která je povinně vygenerována a přiřazena na schválení. Smysluplnost této dohody je diskutabilní, pokud jedna ze skupin musí schvalovat i změny, na jejichž implementaci se nepodílí, nebo daný servis a ani infrastrukturu, na které Změna probíhá, nepodporuje. Také „zastřešující“ IQG workorder sumarizující akceptaci skupin Operations, které se na implementaci podílejí, a z nichž každá se k implementaci vyjadřuje sama za sebe, znamená jen administrativní úkon navíc a nepřináší žádnou další hodnotu. Za zamyšlení stojí schvalování upgrade některé globální aplikace, která je implementována pro jednotlivé země v separátních modulech. Servis pro každou zemi může běžet pod svou vlastní verzí, která je nezávislá na ostatních. Takové “upgrady” mohou být schváleny In principle pro všechny země najednou (pro rámec například celého jednoho příštího roku), ovšem každá implementace pro jednotlivou zemi prochází svým vlastním standardním IQG cyklem. Vzhledem k velkému počtu zemí, pro které je nutno upgrade provést, může 73

nastat situace, že během jednoho týdne je naplánován upgrade i pro deset zemí. To s sebou ovšem přináší deset RFC, deset RTP Plánů a 10xN IQG WO, kde N je obvykle větší než 5. Přitom IQG WO pro každou Změnu schvalují stejné skupiny. V datovém centru jsou zavedeny i různé typy/modely Změn a pre-autorizované Změny, ale tento model nelze pro výše popsané uplatnit pravděpodobně vzhledem k výši rizika, které může být pro každou Změnu jiné a přitom nemalé. Bohužel takový přístup nelze v žádném případě považovat za efektivní. Jiný příklad nabízí samostatný CM proces, který byl dohodnut mezi všemi zúčastněnými stranami pro migrace z jiných datových center DHL. Vzhledem k tomu, že během relativně krátké doby je nutno přesunout do Prahy řádově stovky serverů a servisů, bylo nutno přizpůsobit i Change management proces, aby se s tímto objemem vyrovnal. Došlo k nastavení „zrychlené“ verze fází IA/RA a schvalování In principle. Obojí probíhá na tak zvaném Migračním CABu, na kterém projektový manažer představí rozsah projektu, HW, plán implementace, předpokládaný support model a všechny v té době známé nestandardy. Na vlastním mítinku se zástupci PdS1 (Ops, telecom, Security, Service managementu, Servise Desku, Server Services, Change management skupiny atd.) mají tedy možnost se seznámit a vznést dotazy, na které PM přímo odpoví. Tím se představená Změna (projekt) může buď přímo prohlásit za schválenou In principle nebo se stanoví podmínky, po jejichž splnění je možno Změnu oficiálně považovat za schválenou In principle. Takovýmto nastavením se redukuje standardní schvalovací proces v průměru o dva týdny.

4.2

Týdenní zpracování Změn

V kapitole 3.8 autor popsal týdenní cyklus implementace Změn. Následující graf 1 popisuje vybrané čtyři týdny (cykly) u kterých jsou znázorněny počty jednotlivých druhů Změn, které se daný týden implementovaly, implementace byla odložena a nebo selhala. Z grafu je vidět, že nejpočetnějším druhem implementovaných Změn jsou significant, což jsou závažnější Změny vyžadující downtime služby (patří sem i Projektové – release Změny). Dále následují minor Změny, které většinou jen upravují stávající funkcionalitu. Své zastoupení v grafu mají i migrační Změny, zmíněné v předchozí kapitole. V grafu jsou dále zakresleny rovněž globální Změny, což jsou Změny, které ovlivňují službu mající vlastníka nebo aplikační podporu v APIS.

1

PdS – Production Services pod kterou spadá Operations odd.

74

Zbývající druhy Změn by se daly zjednodušeně označit jako více či méně nežádoucí. Jedná se o Změny, na které sice CM proces pamatuje, ale tyto druhy Změn podstatným způsobem narušují zpracovávaní ostatních Změn nehledě na průběh okolních navázaných procesů. V případě urgentních a emergency Změn jsou totiž vyžadovány neprodlené reakce (revize, schválení, přípravné akce, jednání o výjimkách ap.), které pak následně mohou vyhrotit situaci i u jinak standardně probíhajících Změn, na které tak nezbude čas nebo potřebné zdroje. Odložené Změny jsou pro CM proces menší zlo, jelikož se tak získává dodatečný čas na schválení Změny “standardním” procesem. Přeplánování Změny se však může zkomplikovat situace ostatním účastníkům CM procesu, kteří si svoje aktivity dopředu plánují (implementační týmy, OAT atd.). Graf 1. Přehled schválených Změn za 4 týdny Změny schválené CAB komisí

45 Počet Změn za týden

40

42

Schálené minor Změny

36

38

36

35

31

Schálené significant Změny

29

30

Schálené migrační změy

25 20 15 10 5

21

19 16 13 14 9

15 65 2

3

65

0

15 8

6 2

Globalní změny

14 78

8

Emergency Změny

13 10

4

3 0

Urgentní Změny

5 2

0

0 08 - 14. 2.

15 - 21. 2.

22 - 28. 2.

01 - 07. 3. týden

Odložené Změny Neúspěšné Změny (s dopadem na business)

Zdroj: Vlastní tvorba na základě statistik Change managementu a HPSD

Samotný graf je spíše informačního charakteru. Zobrazené hodnoty oscilují kolem určité hranice. Jediný trend (za celý rok), který tuto oscilaci nějak narušuje, je nárůst projektů v období kolem dubna a září. Na zmíněném grafu je vidět ještě jedna kategorie Změn, která nebyla doposud zmíněna. Jedná se o Změny, které nebyly úspěšně implementovány. Touto otázkou se podrobněji zabývá následující kapitola.

4.3

Emergency Restoration Report

Emergency Restoration Report (ERR) je analýza, která následuje bezprostředně po incidentu, který zásadně narušil dostupnost poskytované služby/služeb1. Obsahem této analýzy je popsání rozsahu incidentu, dopad na byznys, příčinu incidentu, jak a kým byl problém řešen a vyřešen a jaké byly podniknuty preventivní kroky, aby se incident v 1

ERR zajištuje Problem management vlastním procesem na základě závažného – emergency incidentu

75

budoucnu již neopakoval. Součástí tohoto reportu je i popis, zdali daný incident není výsledkem určité Změny, což je hlavní parametr, který nás bude dále zajímat. V předchozí kapitole byly zmíněny neúspěšně implementované Změny. Změna by měla být naplánována tak, aby bylo s případným neúspěchem počítáno a bylo možné službu vrátit zpět do definovaného funkčního stavu. Díky tomu pak nemusí nutně znamenat, že neúspěšně implementovaná Změna způsobí určitý incident. Zároveň však také neplatí, že úspěšně implementovaná Změna nemůže způsobit incident. Následující graf 2 zobrazuje vybraný úsek za rok 2009, rozdělený do měsíců, který popisuje celkový počet ERR a kolik ERR bylo způsobeno Změnou. Tento popis doplňuje informace o počtu neúspěšně implementovaných Změn, společně s celkovým počtem Změn a procentním vyjádřením podílu Změn na ERR. Graf 2. ERR způsobené Změnou

Celkový počet ERR

35

32 30

30

419

25 20

600

37 %

542

35 %

25 400

386

22

319 17

24 % 17

10

430

391

400

349

23 337 22 % 19

320

23 %

23 %

300

20 %

18 %

15

500

30

13

6%

10 %

200

Celkový počet Změn

40

100

5 0

0 Únor

Březen

Duben

Květen

Červen

Červenec

Srpen

Září

Říjen

Listopad

Celkem ERR ERR způsobené Změnou Neúspěšné Změny (s dopadem na byznys) Změny celkem ERR způsobené Změnou [% z celkového počtu ERR]

Zdroj: Vlastní tvorba na základě statistik Change managementu a Problem managementu

Tento graf má rovněž spíše ilustrativní charakter. Z uvedených čísel nelze sledovat jakýkoliv trend nebo vyvozovat nějaké závěry. Pokud budeme uvažovat, že měsíčně cca. 5 Změn z celkových 400 způsobí vážný incident, jedná se o 1,25 %, což je na první pohled poměrně nízké číslo, za kterým se však mohou skrývat velmi vážné a drahé (z pohledu byznysu) incidenty. Proto je zmíněný ERR report primárním zdrojem informací pro jakékoliv hodnocení či hledání nedostatků v CM procesu. V minulosti tak např. došlo na základě ERR k pravidelnému zapojení Security týmu do IQG fáze. Nutno podotknout, že to byl ze stany nedostatků CM procesu ojedinělý případ. Tento fakt naznačuje, že současný CM proces je nastaven správně a nezpůsobuje incidenty, které by si žádaly jeho změnu. 76

4.4

Pozdě příchozí Změny

Následující kapitola je věnována dalšímu závažnému problému, kterému musí CM proces čelit. Tímto problémem jsou pozdě příchozí Změny – konkrétně Projektové. Tento druh Změn prochází celým “základním” CM procesem. Podléhá tedy schválení CAB komisí. To obnáší absolvování fáze Change Impact Analysis & Risk a následně Change Review & Approval. V ideálním případě by proces pro získání požadovaného CAB souhlasu měl následovat neprodleně po ověření platnosti zákaznické objednávky (SO). V předchozích kapitolách autor zmínil, že získáním CAB souhlasu se spouští navazující akce jako např. objednání požadovaného HW, jeho instalace atd. Neadekvátně plánované a řízené projekty se však velmi často dožadují spuštění zmíněných akcí, aniž by Změna byla schválena CAB komisí – tedy aby byla prověřena. Případné udělené výjimky ze strany DHL ITS, založené na eskalacích, pak přímo ohrožují nejen samotné podnikové procesy v podobě dalších nestandardních požadavků na řešení problémů při instalaci řešení, ale následně ohrožují i celé datové centrum v podobě implementace nestandardního řešení a tím pádem nutnosti speciální podpory či určitých výjimek ze stanovené bezpečnostní politiky firmy. „Pozdní Změny“ není možné jednoduše definovat jelikož na ně lze nahlížet z různého úhlu pohledu. Autor dále popisuje dva pohledy – způsoby – jak jsou tyto Změny zjišťovány: Prvním způsobem je sledování, kdy fáze Change Review & Approval překročí vymezenou hranici a začne se překrývat se schvalovací fází pro implementaci Změny. To v praxi znamená, že schválení Změny CAB komisí bylo dosaženo za méně než 101 dní před plánovanou implementací – RTP. Na následujícím grafu 3. jsou zobrazeny průměrné hodnoty zjištěné tímto způsobem za rok 2009. Vypovídající hodnota grafu je především v upozornění na fakt, že vysokých 41% Změn bylo schvalováno v časovém presu. Což může mít za následek vznik zmíněných emergency a urgentní Změn, které tlačí projektové eskalace snažící se o implementaci špatně plánované a většinou i špatně připravené2 Změny emergency procesem. Důsledky těchto aktivit budou diskutovaný v samotném závěru této práce.

1 2

2 dny IARA, 3 dny CAB a 5 dní IQG fáze Špatná dokumentace, testování, implementační plán, předchozí propagace – upozornění na Změnu

77

Graf 3. Pozdě příchozí Změny – rozdíl CAB/RTP Pozdě 41%

Včas 59%

Zdroj: Vlastní tvorba na základě statistik Change managementu a HPSD

Druhým způsobem resp. metodou jak detekovat pozdní Změny je sledování prodlevy mezi potvrzením zákaznické objednávky (SO) a přiřazení RFC do Change management HPSD fronty (zahájení schvalovacího procesu). Tento pohled více vypovídá o špatném plánování projektu, jelikož je vidět prodlevu mezi tím, kdy byl projekt zahájen, a za jak dlouho poté byl vytvořen RFC požadavek. Graf 4. Pozdě příchozí Změny – rozdíl SO/CAB 1 týden

13%

2 týdny 37% 5%

3 týdny 3%

1 měsíc

3% 2 měsíce 3 měsíce 6 měsíc 10% 1 rok 5% 4% 8%

12%

> rok není možné zjistit

Zdroj: Vlastní tvorba na základě statistik Change managementu a HPSD

Z grafu vyplývá, že ~39%1 Změn bylo v roce 2009 přiřazeno do CM HPSD fronty až po více než po měsíci od potvrzení objednávky. Což je stejně jako u předchozího případu veliké a znepokojující číslo mající za následky: zhoršení plánování (např. instalací, OAT apod.), požadavky na již nepodporovaná řešení, patřičné osoby nejsou včas zapojovány do

1

V grafu je rovněž vysoké procento (37%) Projektů u kterých se v důsledku změn v objednávkách, ale i ve vlastních Změnách (vytvoření nové Změny, rozdělění Změny na více částí) se nepodařilo požadovanou dobu zjistit. Tato hodna znepřesňuje vypovídající hodnotu grafu.

78

projektů, projekty jsou vyvíjeny bez potřebného CAB souhlasu a narůstá počet eskalací ze strany byznysu. Pokud bychom v obou zmíněných případech hledali konkrétního viníka, tak je to oddělení Professional Services zastřešující projektový management. Do určité míry by se dalo polemizovat, zdali je větším viníkem samotný byznys a nebo spíše projektový manažer. PM by měl zákazníkovi vysvětlit pravidla a hlavně účel stávajícího procesu a následně sestavit reálný projektový plán respektující zákaznické požadavky a zároveň CM proces. Ale ne vždy je situace natolik ideální, aby to bylo možné. Tudíž nelze svalovat vinu jen na PM, mnohdy je stav již sestaveného projektu – Změny způsoben vedením dané aplikační projektové domény. Pokud projekt změní vícekrát PM nebo je na základě “politických” rozhodnutí přijmout časově poddimenzovaný projekt, je dosti pravděpodobné, že projekt bude v časové tísni a potřebný čas bude využit na úkor dalšího vytváření a zpracování Změny v rámci CM procesu. To znamená, že bude značnou měrou znevýhodňován, utlačován, a nebude dostatek času na potřebné revize Řešení toho problému nespadá přímo do kompetence Change managementu. Z CM pohledu je pouze možné zmíněné ukazatele sledovat a dělat si statistiku pozdě příchozích Změn spolu s označení PM a dané aplikační domény. Na základě výsledků je pak možné usuzovat, zdali je opakující se problém pozdních Změn způsoben jednotlivcem nebo skupinou. Naměřené výsledky jsou pak velmi dobrým materiálem pro další jednání za účelem sjednání nápravy. I když se zdá, že v tomto případě je konkrétní viník jasný, je třeba se zamyslet i nad samotným CM procesem, potažmo jeho dokumentací. Z pohledu procesu je třeba neustále revidovat okolní podmínky/požadavky a pokud je to vhodné nebo méně bolestivé (pracné), tak se jim přizpůsobit. To např. demonstruje zmíněné upravení CM procesu pro migrační změny, které by bylo možné zdlouhavěji implementovat i pomocí stávajícího CM procesu. Rovněž je vhodné revidovat intranetovou dokumentaci CM procesu a popřípadě zvážit vytvoření speciální prezentace či skolení, které by usnadnily jeho chápaní a následné dodržování. Současné autorovi zkušenosti potvrzují fakt, že nízká znalost CM procesu ze strany PM má významný podíl na pozdě příchozích projektech - Změnách.

4.5

Change management proces vs. zákazník

Change management proces je v současné verzi poměrně robustní. Je schopný čelit mnoha situacím a neustále se snaží “bránit“ poskytované byznys služby, ale i samotné 79

infrastrukturní zázemí datového centra. A z předchozích kapitol je i vidět, že je v tomto ohledu poměrně úspěšný – jelikož důvody výpadku služeb jsou z valné časti technické (selhání služby) nebo uživatelské a nikoli způsobené CM procesem. Change management proces se rovněž snaží bránit i samotného zákazníka (projekt) před sebou samým, což dokazují příklady kolidujících Změn (na stejném serveru, službě a ve stejný čas). Pokud by se tyto Změny neodhalily, mohly by společně dané prostředí narušit takovým způsobem, že v případě požadavku na navrácení služby do původního stavu by nebylo možné určit co je třeba a v jakém rozsahu opravit a která Změna to způsobila. Ale i přes tuto svoji robustnost existuje slabina se kterou CM proces vůbec nepočítá. Touto slabinou je podpora vedení. V době psaní této práce čelí DHL ITS velikému počtu migračních a optimalizačních projektů (zejména virtualizace a konsolidace serverů a služeb). Následné projektové Změny jsou ve znepokojivě veliké míře vytvářeny velmi často pozdě a ve špatné kvalitě (plánování, standardy řešení, dokumentace). Tyto Změny nesplňují požadavky na udělení patřičných schválení (CAB, IQG – implementace). Výsledkem by mělo být zamítnutí nebo posunutí Změny, což se ale neděje. Naopak je použita eskalace a Změna je “násilně“ tlačena proti zmíněným standardům a procesům. V případě nedostatků zdrojů nenásleduje nastavení priorit konfliktních Změn – projektů, nýbrž je rozhodnuto byznysem o nutné paralelní implementaci těchto Změn bez ohledu na problémy, které dále nastanou. Tímto způsobem se ale celá organizace vrací do výchozí úrovně (živelně řízené) CMMI 0 a stanovené procesy jsou pouze na obtíž. Odpovědnou osobou za tento stav je jednoznačně nekompetentní management, který je orientován pouze na zákazníka. Ostatní důvody se kryjí s důvody zmíněnými v předchozí kapitole, přičemž hlavním problémem je neznalost procesů a i samotné organizace ze strany projektových manažerů. Řešením této situace je prohlubování znalostí PM a zároveň proaktivního eskalování špatného stavu příchozích Změn směrem k byznysu a užšího vedení ITS. Takto implementované Změny – projekty následně vykazují daleko více provozních chyb, které je nutné řešit a které omezují zákazníka v používání daného řešení. I v tomto neutěšeném stavu je ale nutné stále revidovat CM proces a hledat nedostatky či byrokratické překážky, které většinou existují z určité setrvačnosti postupného vývoje CM procesu a mohou se stát argumentem protistrany upozorňující na to, že Change management proces je špatný.

80

5 Nástroje pro implementaci Všechny dále popsané nástroje mají ve vztahu k současné verzi HPSD používané v DHL ITS jednu společnou věc – vycházejí totiž z nedostatků nebo omezených možností jenž zmíněná HPSD verze poskytuje. Tento fakt bohužel následně fragmentuje jednotný nástroj, potažmo jeho ideu, na relativně nezávislé kusy, které se již hůře integrují a vyžadují si většinou větší péči než jednotný nástroj. Z pohledu uživatelů se pak celý systém stává méně přehledným a transparentním.

5.1

Nástroj HPSD

Hewlett-Packard (HP) Service Desk (SD) je bezesporu hlavním centrálním nástrojem pro podporu všech ITIL Service Support procesů a to zejména Incident, Problem, Change a Konfiguračního managementu. Ve společnosti DHL ITS se konkrétně používá poměrně stará verze 4.5, které byla uvedena na trh v roce 2002. Této verzi končí oficiální podpora ze strany HP koncem roku 20111. Vzhledem k oznámení konci podpory je tak společnost DHL ITS nucena řešit přechod na nový nástroj. Druhým důvodem pro tento přechod je fakt, že současný nástroj je již nevyhovující. A to zejména z pohledu poskytovaných funkcí a rovněž je čím dál horší možnost tyto funkce dále a jednoduše vytvářet či upravovat. Posledním třetím důvodem je již zmíněná rozrůstající se sbírka specifických podpůrných aplikací, v jejichž případě tak nastane ideální čas a možnost je integrovat do nového centrálního nástroje. Tento poslední důvod je ale spíše více vyplývajícím benefitem než jedním z hlavních důvodů pro zmíněný přechod. Autor se dále v této části kapitoly zaměří na analýzu funkčních požadavků na nový systém, která tak upozorní na stávající nedostatky HPSD.

Specifikace požadavků na nový systém •

RFC a WO by měli být zabezpečeny – requestor, implementátor a všichni, kdo revidují Změnu, by měli být schopni zasahovat (měnit) RFC jen na určených místech a v určité fázi životního cyklu Změny,

•

Všechna přiložená dokumentace by měla být v určitých fázích zamčena – nikdo už by tak např. nemohl dělat změny v již odsouhlaseném RTP plánu,

1

Zdroj: http://h20230.www2.hp.com/pdf/SD4_5_ObsCustLtr.pdf

81

•

Přiložené dokumenty musí být auditovatelné – musí být integrována kontrola verzí,

•

Životní cyklus Změny by měl být řízen byznys logikou – každý účastník CM procesu by mohl mít právo měnit status Změny v definovaných mezích při splnění definovaných podmínek (např. určitý status jiných WO apod.),

•

Integrovaný katalog pre-autorizovaných Změn,

•

Integrovaný nástroj Forward Schedule of Changes (FSC),

•

Podpora implementace Změny ve více vlnách/částech – možnost navázat skupinu RFC pod hlavní RFC,

•

Automatické Zamykání RFC při její editaci nebo umožnění paralelní editace stejného RFC požadavku více uživateli – vyřešení konfliktů ukládání Změny ve stávajícím HPSD více uživateli ve stejný čas,

•

Vkládání formátovaného nebo HTML textu včetně obrázků (screenshots) bez nutnosti přikládání samostatných souborů,

•

Dynamicky vytvářený obsah RFC formulářů – dle kategorie, rizika atd.,

•

Různé druhy kalkulace deadline pro splnění daného úkolu – současný stav v HPSD neposouvá deadline v případě čekání na requestorovu odpověď. Přiřazené osobě se tak krátí čas na splnění úkolu i v případě, kdy nemůže pokračovat (např. z důvodu čekání na doplňující informace).

Migrace HPSD na Service Manager Společnost HP nabízí stávajícím zákazníkům (s platnou podporou HPSD 4.5) možnost bezplatné1 migrace na produkt Service Manager 7.0 obsahující stejné komponenty (např. nástroje na monitoring), které zákazník využívá. Tato možnost spolu s nabídkou určité migrační podpory je tak hlavním důvodem pro zvážení této nabídky. Hlavní důvody pro samotnou migraci na SM7 jsou:
Bezplatný přechod na SM7 včetně potřebných komponent,
Jedná se o produkt od stejné firmy a s tím spojená migrační a následná podpora,
Určité migrační nástroje umožňující částečnou automatizaci - zjednodušení migrace.

1

Bezplatný je pouze přechod, za potřebné licence pro provoz SM7 se již platí

82

Existují však i důvody, které je nutné před samotnou migrací důkladně prověřit. Těmito důvody je například fakt, že SM7 nesdílí s HPSD stejnou technickou architekturu řešení – SM7 je totiž původem jiný produkt. Teto fakt dokládá skutečnost, že HPSD je postaven nad relační databází1 oproti flat file2 databázi využívanou SM7. To v konkrétním případě aplikace CLOB3, BLOB4 formátu podstatně snižuje následnou orientaci v datové struktuře SM7 databáze, což např. vede k obtížnějšímu tvoření reportů – je třeba znát formát ukládaných dat. Rovněž není možné zmigrovat stávající data (RFC, SC, Incidenty) obsažené v HPSD do SM7. To znamená, že všechny doposud získané informace (migrační plány, RTP plány, a další přílohy Změn) budou ztraceny. Tyto a mnohé další příklady pak v rozměrech DHL ITS budou podstatným způsobem ovlivňovat samotnou migraci, která je v tomto obrovském měřítku sama o sobě ojedinělá.

5.2

Nástroj IQG manager

IQG manager je web-based5 aplikace sloužící pro zjednodušení přípravy Forward Schedule of Changes (FSC), jednoduše řečeno IQG agendy pro daný týden. Tato webová aplikace využívá data obsažená v HPSD. Jedná se především o RFC samotné a dále informace o ovlivněných serverech – Configuration Item (CI) a na ně navázaných služeb. Primárním uživatelem této aplikace je skupina TI leaderů řídící release (significant a major) Změny. Tato skupina si na týdenní bázi rozděluje nově vytvořené změny v HPSD. Tímto způsobem je o nových Změnách informována v předstihu, i když samotná Změna se může nacházet třeba v IA/RA nebo CAB fázi, což jsou fáze, kdy je Změna přiřazena stále v Change management HPSD frontě. TI leader má tak možnost jednoduše sledovat „své“ změny a případně schvalovací postup korigovat. V případě požadavku na implementaci Změny je TI leader povinen vyplnit kartu Změny v IQG4You. Do této karty se zadávají informace typu: krátký popis Změny, délka případného

výpadku

(downtime) služby,

seznam

všech

skupin

účastnících

se

implementace, jméno koordinátora implementace, hodnocení kvality připravenosti Změny a požadované priority. Poslední dva parametry slouží pro interní účely, zejména pro

1

Viz http://cs.wikipedia.org/wiki/Rela%C4%8Dn%C3%AD_datab%C3%A1ze Je relativně jednoduchý databázový system, který uchovává každou databázi ve formě jednoduché tabulky vice viz. http://en.wikipedia.org/wiki/Flat_file_database 3 Character large objects (CLOB) je označení pro datový typ ukládaný ve formě dlouhých textových řetězců 4 Binary large object (BLOB) je označení pro datový typ blíže nespecifikovaných binárních dat v databázi 5 Web-based aplikace je aplikace, která je dostupná pomocí internetového prohlížeče a to přez Internet nebo Intranet 2

83

reportování, jaký typ změn je implementován, kolik Změn přichází pozdě do TI lad. fronty a jak kvalitně jsou připravené. Obrázek 25. Nástroj IQG4you – seznam Změn

Zdroj: Vlastní tvorba

Budoucnost IQG4You IQG4You je bezesporu užitečným web-based nástrojem, který velmi dobře splňuje svoji funkci a oproti předchozímu stavu podstatně ulehčuje práci s přípravou FSC. Tento stav je však velmi rychle pomíjivý, což platí dvojnásob v dynamickém prostředí DHL ITS. I přes svoji užitečnost je si třeba uvědomit, že se stále jedná jen o řešení chybějící HPSD funkcionality. Uživatel tohoto systému, primárně skupina TI leaderů, totiž znovu vyplňuje určité informace, které již RFC požadavek obsahuje. Příprava většího počtu Změn se pak z tohoto důvodu stává poměrně časově náročnou administrativní prací. Tento způsob práce rovněž vytváří prostor pro možnou lidskou chybu a štěpí informaci o RFC, kterou Change management v podobě připravené agendy dále zpracovává. Z tohoto pohledu se stává budoucí vývoj této aplikace poněkud neperspektivní. IQG4You aplikace, respektive funkce, kterou poskytuje, by měla být v budoucnu obsažena v samotném SD nástroji. Odpadne tak možnost lidských chyb, částečně administrativa a Change management získá větší přehled a kontrolu na plánovanými Změnami.

84

5.3

Online SBF

Samotný SBF svou podstatou nespadá pod Change management proces, tudíž by v této části teoreticky neměl mít své místo. Autor je ale toho názoru, že SBF dokument je v daném případě pro Change management velmi důležitý. SBF je totiž v úvodních kontrolních fázích (IA/RA, CAB) zásadním zdrojem informací. Dostupnost a přehlednost informací mají velký vliv na rychlost zmíněných kontrolních fází. SBF je, resp. by měl být, jak je popsáno v následující kapitole, velmi těsně spjat s CMDB Konfiguračního managementu. A uvědomme si, že bez CMDB není Change management realizovatelný. Server Build Form byl původně elektronický, dokument jenž umožňoval requestorovi podrobnou specifikaci požadovaného serveru (např. HW; verzi operačního systému; kapacitu, druh a rozdělení diskového prostoru; middleware aplikace; specifikace uživatelského přístupu aj.). Tento dokument se vkládal formou přílohy do RFC požadavku. SBF byl vždy spjat s konkrétní RFC a byl tak i vlastně zálohován. HPSD 4.5 bohužel neumožňuje sofistikovanější prohledávání příloh RFC. V případě potřeby je tak obtížné prohledávat tisíce Změn. Rovněž wordovský dokument, ve kterém byl SBF dokument vytvořen, nenabízí dostatečné prostředí pro vytvoření více uživatelsky přívětivějšího formuláře, který by sám napomáhal při jeho vyplňování a zobrazoval jen relevantní možnosti, které by tak zbytečně nezahlcovaly requestora. Obrázek 26. Server Build Form – konkrétní příklad

Zdroj: Interní materiály společnosti DHL ITS

85

Všechna tato negativa jasně definovala požadavky na novou formu SBF. Touto formou se opět stala webová aplikace, sdílející stejné prostředí (server) a zdroje jako IQG4You. Díky tomu jsou obě aplikace daleko lépe provázané a rovněž i samotná podpora je jednodušší. Vraťme se ale k popisu vlastností online SBF verze. Tolik chybějící uživatelský komfort byl implementován a výsledná kvalita vyplňovaných dokumentů se podstatným způsobem zvýšila. Implementován byl i systém zámků jednotlivých SBF „dokumentů“, umožňující kontrolu nad novými požadavky, což u dřívějšího dokumentu nebylo možné. Odpadají tak následné dohady s projektem o tom co bylo opravdu žádáno a co bylo nainstalováno. Jednotlivá SBF se v případě rozsáhlých projektů dají jednodušeji kopírovat.

Propojení SBF a CMDB Online verze SBF dokumentu se velmi osvědčila a to nejen u samotných „zákazníků“, ale i u ostatních uživatelů – tj. u skupiny instalující servery, TI leaderů, Capacity managementu a Operations provádějící OAT testy. Nedávno je začal využívat i skupina License managementu zajištující potřebné licence pro aplikace specifikované v SBF. Po skončení OAT testování obsahuje SBF dokument přesný popis serveru a jeho konfigurace. Případné nesrovnalosti vzniklé při instalaci, konfiguraci a dolaďování aplikací jsou totiž v průběhu OAT řešeny a samotný SBF je ihned aktualizován. SBF tak poskytuje zdroj aktuálních informací jež by bylo vhodné využít pro aktualizaci CMDB. V současné době zajišťuje aktualizaci CMDB výhradně Konfigurační management, který v daných fázích (většinou na základě určitého workorderu) vytváří, či aktualizuje jednotlivé CMDB položky (CI). V praxi se ale stává, že aktualizace či vytvoření některého CI musí být Konfiguračnímu managementu připomenuta a to např. kvůli lidské chybě, přetíženosti oddělení nebo urgentní žádosti o vytvoření CI, jelikož z CMDB extrahují potřebná data i další aplikace. Spojením těchto nástrojů by se eliminovala lidská chyba a případná přetíženost Konfiguračního managementu. Ošetření nestandardních situací (dat) na automatizovaných vstupech je možné řešit programově, popřípadě je možné poslat emailové upozornění, na jehož základě může konkrétní pracovník situaci dále prověřit. Další profitující skupinou, která je životně závislá na aktuálních a přesných informacích v CMDB, je Change management. V současné době jsou incidenty způsobené neaktuálností CMDB velmi výjimečné, nicméně existují případy které snižují důvěryhodnost CMDB resp. aktuálnost dat, která obsahuje.

86

Závěr Change management proces je velmi komplexním a mocným nástrojem, musí však stále pamatovat na základním principy ITILu. V konkrétních podmínkách DHL ITS, to znamená především orientaci na zákazníka a řízení Změn v datovém centru. Zde však dochází k prvotnímu střetu zájmů. Byznys chce své požadavky – Změny - implementovat co možná nejdříve. Naopak Change management se snaží o adekvátní prověření všech Změn tak, aby bylo zaručeno, že nebudou ohroženy produkční služby poskytované zákazníkům. To si však vyžaduje určitý čas. V budoucnu by se proto společnost DHL ITS měla zaměřit na více proaktivní přístup v prezentaci stávajícího CM procesu, aby zákazník – byznys - měl přehled, co je cílem tohoto procesu, jaké podmínky musí splnit a jak má své požadavky (projekty) plánovat. Ze strany DHL ITS je třeba eliminovat veškerá nadbytečná a nice to have1 místa v CM procesu, která nepřidávají žádnou hodnotu a naopak jej v jakékoli míře prodlužují. V rámci organizace je nutné prosadit taková opatření, která zaručí, že nedomyšlené či nesmyslné Změny budou zastaveny již na samotném začátku CM procesu a nebudou dále zatěžovat zdroje organizace. Tyto zdroje tak získají více času pro řešení nestandardních situací u jinak dobře připravených Změn. To napomůže i rychlejšímu vytváření nových standardů, které mohou zákazníci v budoucnu dále využívat. Současný stav vytížení datového centra a problémy špatného plánovaní této snaze velmi úspěšně komplikují cestu. Dalším ze zásadních problémů, který zapříčiňuje mnohá nedorozumění mezi zákazníkem a DHL ITS, je neúčast technických specialistů ve fázi vytváření nabídky daného řešení zákazníkovi. Tuto roli již nějakou dobu supluje BID management a nutno podotknout, že poměrně neúspěšně. Zákazníkovi jsou nabídnuta polovičatá nebo nestandardní řešení, které v pozdější fázi “Create change package” není možné splnit. Účast zmíněných specialistů na kvotaci je proto v budoucnu bezpodmínečně nutná. Change management proces je rovněž koncipován tak, aby svým systematickým přístupem přispíval ke snížení provozních nákladů. Což je v současném stavu další sporný parametr. Zpravidla pokud je implementována Změna pod eskalačním tlakem, není čas na nutné testování a následné problémy jsou detekovány až při živém provozu aplikace. Jakýkoliv další zásah, či změna konfigurace aplikace musí znovu projít CM procesem. To opět brzdí projekt a následné eskalace na sebe nedají dlouho čekat. Zákazník v konečném důsledku 1

Nice to have - “hezké mít”

87

docílí pouze toho, že jeho aplikace je bez dodatečných úprav většinou nepoužitelná a CM proces tak musí čelit dalším nechtěným urgentním a emergency Změnám, které musí být revidovány, schvalovány a implementovány. Řešení tohoto problému bylo diskutováno již v Kap. 4.4 a 4.5. Posledním bodem, který bude nutné v blízké budoucnosti řešit, je rozdílný CM proces používaný v pražském datovém centru a v APIS. V současné době plné rozsáhlých migrací a konsolidací dochází k větší míře přesunu aplikací mezi zmíněnými datovými centry. Jednotlivé Změny tak poměrně často řeší požadavky ovlivňující služby vlastněné APIS Service ownerem nebo požadují spolupráci s APIS skupinami. Současný způsob schvalování takovýchto Změn je pro Change management zbytečně zdlouhavý a pracný. Rovněž dochází ke zbytečným nedorozuměním, jelikož obě strany používají jiný CM proces. Proto je nutné začít spolupracovat na jednotném procesu, který bude na obou stranách také stejně chápan a dodržován. Autor strukturoval diplomovou práci tak, aby se jednotlivé kapitoly postupně doplňovaly a dostatečně tak vynikly všechny kladné a záporné vlastnosti CM procesu na konkrétním příkladu organizace. Pro lepší pochopení daného tématu autor použil své vlastní zkušenosti a názorné příklady z praxe. Fakta a tvrzení jsou tak podložena „hmatatelnými“ argumenty, které umožní čtenáři daleko rychlejší pochopení do dané tématiky. Tato práce tak poskytuje nejen nutný teoretický přehled, ale také praktický příklad implementace, včetně praktických zkušeností, zhodnocení nedostatků CM procesu a použitých nástrojů spolu s doporučeními ve směrem dalšího vývoje. V rámci vlastní práce se tak podařilo dosáhnout stanoveného cíle a práce je svým obsahem a strukturou přínosem.

88

Seznamy použitých zdrojů Seznam použité literatury 1. Service Manager for Service Support. US : [s.n.], Hewlett-Packard, 2007. 456 s. [citace 2010-02-20] 2. Office Government Commerce. Best Practice for Service Support. London : The Stationery Office, 2000. 299 s. ISBN 0113300158. 3. RUDD, Colin; HODGKISS, Gary; CARTLIDGE, Alisson. Úvodní přehled ITIL® : Verze 1.0a. Česká Republika : S&K Management Systems, spol. s r.o, 2004. 48 s. 4. CARTLIDGE, Alison, et al. Úvodní přehled ITIL® V3 : Verze 1.0. Česká Republika : Hewlett-Packard s. r. o., 2007. 58 s. ISBN 0-9551245-8-1. 5. itSMF. ITIL® v3 Slovníček termínů, definic a zkratek : V2.0. Česká Republika : ItSMF Czech Republic, o.s.,, 2008. 74 s. 6. Interní materiály DHL Information Services (Europe) s.r.o.

Seznam internetových zdrojů 1. WIKIPEDIA. ITIL - [citace 2010-01-04], dostupný z: http://cs.wikipedia.org/wiki/Information_Technology_Infrastructure_Library 2. HN. ITIL a Cobit - [citace 2010-01-10], dostupný z: http://hn.ihned.cz/c114454590-itil-a-cobit-ridi-komunikacni-technologie 3. TELEFÓNICA O2. ITIL - [citace 2010-01-10], dostupný z: http://www.itil.cz/index.php?id=8 4. GETRONICS CONSULTING. ITIL V3 - [citace 2010-01-10], dostupný z: http://www.best-managementpractice.com/gempdf/White_Paper_TOGAF_9_ITIL_V3_Sept09.pdf 5. HP. ITIL - [citace 2010-01-10], dostupný z: http://h10126.www1.hp.com/services/integrace/itsm/files/podrobne_informace_o_it il.pdf

89

Seznam zkratek Zkratka AMIS APIS BUIT CAB CI CIO CM CMDB CMMI DSL EC EMEA ERR FSC HPSD HTML HW IARA ICT IQG IT ITIL ITSM OAT OS PdS PIR PM RFC RTP SAN SBF SD SLA SLM SM SO SO SPOC SW TAT TI TIL UAT US WO

Popis American Information systems Asia Pacific Information systems Business Unit IT Change Advisory Board Configuration Item Chief Information Officer Change Management Configuration Management Database Capability Maturity Model Integration Definitive Software Library Emergency Committee Europe, the Middle East and Africa Emergency Restoration Report Forward Schedule of Changes Hewlett-Packard Service Desk Hypertext Markup Language Hardware Impact Analysis & Risk Assessment Information and Communications Technology Implementation Quality Gate Information Technology Information Technology Infrastructure Library Information Technology Service Management Operations Acceptance Test Operating System Production Services Post Implementation Review Project Manager Request for Change Release To Production Storage Area Network Server Build Form Service Desk Service Level Agreement Service Level Management Service Manager Sales Order Service Owner Single Point Of Contact Software Technical Acceptance Test Technical Implementation Technical Implementation Leader User Acceptance Test United States Work Order

90

Překlad Americké IS Asie Pacifik IS Obchodní IT jednotka Poradní výbor pro změny Konfigurační položka Správa změn Databáze správy konfigurací Metodologie CMMI Knihovna definitivních SW prvků Výbor pro naléhavé změny Evropa, střední východ a Afrika

Hardware Informační a komunikační technologie Informační technologie Knihovna infrastruktury IT Správa služeb IT Akceptační testy systémové podpory Operační systém Revize po implementaci Projektový manažer Požadavek na Změnu Uvedení do produkce

Dohoda o úrovních služeb Správa úrovní služeb Správce služeb Objednávka Vlastník služby Centrální kontakt Software Akceptační testy aplikační podpory oddělení Technické implementace Vedoucí technické implementace Uživatelské akceptační testy Spojené Státy Pracovní příkaz (obsahuje potřebné instrukce k provedení příkazu)

Slovník důležitých pojmů Tento slovník byl převzat a částečně poupraven ze “Slovníku Správy služeb IT“ vydaného itSMF Česká Republika. Anglický výraz

Český výraz

Popis

Application

Aplikace

Back-out Plan

Plán uvedení do původního stavu

Software, který poskytuje funkce požadované službou IT. Každá aplikace může být částí více služeb IT. Aplikace běží na jednom nebo více serverech anebo klientech. (Change Management) (Release Management) Plán, který dokumentuje kroky potřebné pro znovuuvedení do známého funkčního stavu, pokud Změna nebo release neproběhly úspěšně.

Best Practice

Nejlepší praktiky

Osvědčené činnosti nebo procesy, které byly úspěšně použity několika organizacemi. ITIL je příkladem nejlepších praktik

Build

Build (Sestavení)

Business

Byznys

Business Service

Služba byznysu

Capability Maturity Model Integration (CMMI)

Integrační model zralosti (Capability Maturity Model Integration/ (CMMI)

Capacity

Kapacita

Configuration Item (CI)

Konfigurační položka (KP)

Configuration Management Database (CMDB)

Konfigurační databáze (CMDB)

Customer

Zákazník

Deployment

Nasazení

Downtime

Výpadek

(Release Management) Sestavení několika konfiguračních položek tak, aby vytvořily službu IT. Termín build se také používá pro release, který je schválen k distribuci. Například Server build nebo laptop build. Společenská entita nebo organizace, která se skládá z více podnikových jednotek. V kontextu ITSM výraz byznys zahrnuje veřejný sektor a neziskové organizace stejně jako firmy. Poskytovatel služby IT poskytuje službu IT zákazníkovi v rámci byznysu. Provozovatel služby IT může být součástí stejné firmy jako jeho zákazník (interní poskytovatel služby) anebo částí jiné firmy (externí poskytovatel služby) Služba dodávaná zákazníkovi byznysu podnikovou jednotkou. Např. dodávka finančních služeb zákazníkovi banky nebo dodávka zboží zákazníkovi maloobchodu. Úspěšné dodání služby byznysu často závisí na jedné nebo více službách IT Integrační model zralosti (CMMI) je přístup k vylepšování procesů vyvinutý institutem Software Engineering Institute (SEI) na Univerzitě Carnegie Melon. CMMI poskytuje organizacím základní charakteristiky efektivních procesů. Může být použit jako směrnice pro zdokonalení procesů v projektu, divizi nebo celé organizaci. CMMI pomáhá integrovat tradičně rozdělené organizační funkce, nastavovat cíle a priority zdokonalování procesů, poskytuje návod pro řízení kvality a slouží jako referenční úroveň pro ohodnocení stávajících procesů. Další informace jsou dostupné na http://www.sei.cmu.edu/cmmi/. (Capacity Management) Maximální propustnost (výkon) kterou může konfigurační položka nebo služba IT poskytovat při dodržení dohodnutého cíle úrovně služeb. Pro některé typy konfiguračních položek může kapacita představovat velikost nebo množství, např. u diskových jednotek. (Configuration Management) Jakákoliv komponenta, která by měla být spravována za účelem dodávky služby IT. Informace o všech CI jsou zaznamenány v konfiguračním záznamu v CMDB a jsou udržovány během jejich životního cyklu Správou konfigurací. KP jsou řízeny Správou změn (Change Management). KP typicky zahrnují hardware, software, stavby, lidi a formalin dokumentaci, jako dokumentaci procesů a smluv SLA. (Configuration Management) Databáze užívaná pro správu konfiguračních záznamů (KP) během jejich životního cyklu. V CMDB jsou zaznamenány atributy každé KP a vazby na další KP. CMDB může obsahovat také další informace s vazbou na KP, např. záznamy o incidentech, problémech a změnách. CMDB je udržována Správou konfigurací (Configuration Management) a je využívána všemi procesy Správy služeb IT. Někdo, kdo kupuje zboží nebo služby. Zákazník poskytovatele služeb IT je osoba nebo skupina, která definuje cíle úrovně služeb a schvaluje je. Pojem Zákazník bývá někdy neformálně užíván ve smyslu Uživatel, např. "zákaznicky zaměřená organizace“. (Release management) Činnost, zodpovědná za nasazení (začlenění) nového nebo změněného hardware, software, dokumentace, procesu atd. Do produkčního živého provozu. (Availability Management) Období, kdy konfigurační položka (KP) nebo služba IT není během dohodnuté provozní doby dostupná. Dostupnost služby IT je často kalkulována z dohodnuté provozní doby a výpadku.

91

Escalation

Eskalace

Change Advisory Board (CAB)

Poradní výbor pro změny, (CAB)

Change Advisory Board / Emergency Committee (CAB/EC)

Poradní výbor pro změny / výbor pro naléhavé změny (CAB/EC)

Change

Změna

Change Management

Správa změn

Change Request (RFC)

Změnový požadavek

Impact

Dopad

Incident

Incident

Infrastructure

Infrastruktura

IT Operations

Provoz IT

IT Service

Služba IT

Live Environment Operational Acceptance

Produkční (živé) prostředí Provozní akceptace

Policy

Politika

Priority

Priorita

Procedure

Postup

Process

Proces

Process

Vlastník

Získání dodatečných zdrojů, pokud jsou vyžadovány pro dosažení úrovní služeb nebo očekávání zákazníka. Eskalace může být potřebná v jakémkoli procesu služeb IT, avšak je obvykle spojena se Správou incidentů, se Správou problémů a Správou stížností zákazníků. Jsou dva typy eskalací: funkční eskalace a hierarchická eskalace. (Change management) Skupina lidí, která asistuje manažerovi změn při jejich posuzování, určení jejich priority a při jejich plánování. Tento orgán je obvykle tvořen reprezentanty všech oblastí poskytovatele služeb IT, reprezentanty byznys a třetích stran, např. dodavatelů. (Change Management) Podskupina poradního výboru pro změny, která rozhoduje o naléhavých změnách. O členství ve výboru (CAB/EC) se může rozhodovat až v době, kdy je svolána schůzka, závisí to na povaze naléhavé změny.

(Change management) Přidání, modifikace nebo odstranění čehokoliv, co by mohlo mít vliv na služby IT. Změny by měly zahrnovat všechny konfigurační položky, procesy, dokumentaci atd. (Change Management) Proces, odpovědný za řízení životního cyklu všech změn. Primárním cílem Správy změn je umožnit realizaci prospěšných změn při minimálním narušení služeb IT. Formální návrh na provedení změny. RFC obsahuje detaily navrhované změny a může být zaznamenán papírově nebo elektronicky. Pojem RFC je často nesprávně používán ve smyslu záznamu o změně nebo ve smyslu změny samotné Míra účinku incidentu, problému nebo změny na podnikové procesy. Dopad je často založen na tom, jaký vliv bude mít na úroveň služby. Dopad a naléhavost jsou užívány pro přiřazení priority. (Incident Management) Neplánované přerušení služby IT nebo omezení kvality služby IT. Každá událost, která by mohla v budoucnu mít dopad na službu IT, je také incident. Např. chyba jednoho disku ze zrcadlící sady. Z pohledu správy služeb IT je termín používán pro označení všech komponent (konfiguračních položek) účastnících se procesu dodávky IT služeb uživatelům, včetně výpočetní a telekomunikační techniky, programového vybavení, služeb, lidí, dokumentace a meta-dat. Z pohledu byznysu je infrastruktura sdíleným zdrojem, vymezujícím přizpůsobivost a schopnost změn organizace. Odpovídá za každodenní sledování a správu jedné či více služeb IT a infrastruktury nezbytné pro jejich poskytování. Termín provoz IT je užíván také pro označení skupiny či oddělení odpovědné za provoz IT. Služba poskytovaná jednomu nebo více zákazníkům. Služba IT je založena na využití informační technologie a podporuje podnikové procesy zákazníka. Služba IT je vytvářena za pomoci personálu, procesů a techniky a měla by být definována v dohodě o úrovni služeb (Service Level Agreement). Řízené prostředí obsahující aktuální konfigurační položky použité k poskytování služeb IT zákazníkovi. (Release Management) Část akceptace releasu, odpovědná za to, že všechny náležitosti nezbytné pro provoz IT jsou splněny před nasazením releasu. Při provozní akceptaci je často užíván kontrolní seznam (checklist), sloužící k ujištění, že jsou k dispozici požadovaná dokumentace, provozní procesy IT, nástroje a výcvik. Formálně dokumentovaná očekávání a záměry vedení. Politiky jsou využívány k přímým rozhodnutím a zajištění konzistentního a vhodného rozvoje a implementaci procesů, norem, rolí, činností, infrastruktury IT atd. Kategorie používaná pro identifikaci relativní významnosti incidentu, problému nebo změny. Priorita je založena na dopadu a urgentnosti, je užívána pro identifikaci potřebného času pro činnosti, které je nutno provést. Např. SLA může určit, že incidenty s prioritou 2 musí být vyřešeny do 12 hodin. Dokument obsahující kroky, které specifikují, jak uskutečnit činnost. Postupy jsou definovány jako část procesů. Strukturovaná množina činností navržená pro dosažení určitého specifického cíle. Proces má jeden či více definovaných vstupů a přetváří je do definovaných výstupů. Proces může obsahovat jakékoli role, odpovědnosti, nástroje a řídící prvky požadované pro spolehlivou dodávku výstupů. Proces může v případě potřeby definovat politiky, normy, pokyny, činnosti a pracovní instrukce. Role odpovídající za splnění účelu procesu. Odpovědnostmi vlastníka procesu jsou sponzorování, návrh a řízení změn procesu a jeho metrik. Role je často přiřazena tomu, kdo zastává roli procesního manažera, avšak tyto role mohou

92

Owner

procesu

být u větších organizací odděleny.

Project

Projekt

Release

Release

Review

Revize

Role

Role

Service

Služba

Service Owner

Vlastník Služby

Dočasná struktura, zahrnující osoby a další zdroje nezbytné k dosažení cíle. Každý projekt má svůj životní cyklus, který typicky obsahuje zahájení, plánování, realizaci, ukončení atd. Projekty jsou obvykle řízeny podle formálních metodologií jako například PRINCE2. (Release Management) Soubor hardware, software, dokumentace, procesů nebo dalších komponent požadovaných pro implementaci jedné nebo více schválených změn služeb IT. Obsah každého releasu je spravován, testován a implementován jako jedna entita. Vyhodnocení změny, problému, procesu, projektu atd. Revize jsou typicky prováděny v určitých bodech životního cyklu, obzvláště po uzavření. Účelem revize je zajistit, aby byly poskytnuty všechny dodávky, a identifikovat příležitosti pro zlepšení. Soustava zodpovědností definovaných v procesu, jimiž je pověřena osoba nebo tým. Jedna osoba nebo tým mohou mít více rolí, např. role manažera konfigurací nebo manažera změn může být vykonávána stejnou osobou. Poskytování hodnoty nehmotného charakteru zákazníkovi. Např. bankovnictví nebo právní služba. Také synonymum pro službu IT. Jednotlivec nesoucí primární odpovědnost za službu včetně návrhu, cílů a vývoje

System

Systém

User

Uživatel

Množina souvisejících elementů, působících společně v zájmu dosažení určitého cíle. Např. • Počítačový systém obsahující hardware, software a aplikace. • Systém správy procesů plánovaných a řízených společně. Např. Systém pro řízení kvality (Quality Management System). • Systém správy databáze nebo operační systém zahrnující mnoho softwarových modulů navržených k vykonávání soustavy funkcí. Osoba používající každodenně službu IT. Uživatelé se odlišují od zákazníků tím, že někteří zákazníci nemusí přímo službu IT používat.

Seznam obrázků OBRÁZEK 1. JEDNOTLIVÉ KOMPONENTY PROCESNÍ ORGANIZACE DHL............................................................11 OBRÁZEK 2. STRUKTURA PROCESŮ VE FIRMĚ DHL NA NEJVYŠŠÍ ÚROVNI.........................................................12 OBRÁZEK 3. RÁMCOVÝ MODEL ITIL ................................................................................................................16 OBRÁZEK 4. MODEL ITIL V3............................................................................................................................19 OBRÁZEK 5. DEMINGŮ CYKLUS.........................................................................................................................21 OBRÁZEK 6. MAPOVÁNÍ PROCESŮ ITIL V2 – ITIL V3 ......................................................................................21 OBRÁZEK 7. PROPOJENÍ CM S OKOLNÍMI PROCESY ...........................................................................................25 OBRÁZEK 8. ÚVODNÍ EVIDENCE ZMĚN..............................................................................................................27 OBRÁZEK 9. POSOUZENÍ A SCHVÁLENÍ RFC .....................................................................................................28 OBRÁZEK 10. TVORBA A IMPLEMENTACE ZMĚN ...............................................................................................30 OBRÁZEK 11. SCHÉMA DHL CHANGE MANAGEMENT PROCES ..........................................................................33 OBRÁZEK 12. RFC V HPSD NÁSTROJI ..............................................................................................................35 OBRÁZEK 13. CM CHECKLIST - DEFINICE ROZSAHU ZMĚNY ............................................................................36 OBRÁZEK 14. CHANGE INITIATION FÁZE ..........................................................................................................43 OBRÁZEK 15. IA/RA WORKORDERY V HPSD ...................................................................................................45 OBRÁZEK 16. IA/RA FÁZE ................................................................................................................................47 OBRÁZEK 17. CAB APPROVAL WO V HPSD....................................................................................................50 OBRÁZEK 18. CAB (APPROVAL IN PRINCIPLE) FÁZE.........................................................................................51 OBRÁZEK 19. PŘÍKLAD OAT WO V HPSD .......................................................................................................55 OBRÁZEK 20. PŘÍKLAD IQG WO V HPSD .......................................................................................................60 OBRÁZEK 21. CREATE CHANGE PACKAGE FÁZE ................................................................................................61 OBRÁZEK 22. IMPLEMENT CHANGE FÁZE ..........................................................................................................64 OBRÁZEK 23. REVIEW CHANGE AND CLOSE FÁZE..............................................................................................66 OBRÁZEK 24. TÝDENNÍ CYKLUS ZPRACOVÁNÍ ZMĚN ........................................................................................67 OBRÁZEK 25. NÁSTROJ IQG4YOU – SEZNAM ZMĚN..........................................................................................84 OBRÁZEK 26. SERVER BULD FORM – KONKRÉTNÍ PŘÍKLAD ..............................................................................85

93

Seznam tabulek TABULKA 1. VÝHODY A NEVÝHODY PROCESNÍHO ŘÍZENÍ ...........................ERROR! BOOKMARK NOT DEFINED. TABULKA 2. VÝHODY A NEVÝHODY PROCESNÍHO ŘÍZENÍ .................................................................................10 TABULKA 3. FORMÁLNÍ ČÁSTI SCHVALOVACÍHO PROCESU ...............................................................................29 TABULKA 4. RELEASE A ROUTINE KATEGORIE ZMĚN........................................................................................38 TABULKA 5. KATEGORIZACE ZMĚN PODLE ÚROVNĚ RIZIKA ..............................................................................41 TABULKA 6. PRIORITA ZMĚNY ..........................................................................................................................42 TABULKA 7. ROZDĚLENÍ ZODPOVĚDNOSTÍ ........................................................................................................53 TABULKA 8. ČÁST RTP DOKUMENTU SPECIFIKUJÍCÍ IMPAKTOVANÉ CI ............................................................56 TABULKA 9. ČÁST RTP DOKUMENTU................................................................................................................57 TABULKA 10. SCHVALOVACÍ MATICE ...............................................................................................................60 TABULKA 11. POPIS EMERGENCY A URGENT PROCESŮ........................................................................................70

Seznam grafů GRAF 1. PŘEHLED SCHVÁLEMÝCH ZMĚN ZA 4 TÝDNY.......................................................................................75 GRAF 2. ERR ZPŮSOBENÉ ZMĚNOU ..................................................................................................................76 GRAF 3. POZDĚ PŘÍCHOZÍ ZMĚNY – ROZDÍL CAB/RTP .....................................................................................78 GRAF 4. POZDĚ PŘÍCHOZÍ ZMĚNY – ROZDÍL SO/CAB .......................................................................................78

94

Přílohy Elektronická podoba této práce je uložena na CD. Medium je přiloženo k první kopii této práce na zadní straně desek. Příloha 1 Charakteristika ITIL modulů The Business Perspective (Perspektiva byznysu): Poskytuje IT personálů návod, jak přispět k obchodním cílům a jak vlastní IT služby mohou být lépe přizpůsobené pro maximalizaci jejich příspěvku. Tento modul zdůrazňuje fakt, že všichni jsme jedna organizace, jeden byznys a měly bychom pracovat tak, aby bylo dosaženo všech obchodních cílů. Součástí jsou návody jak řídit IT zdroje z pohledu byznys priorit. Pro řízení z byznys perspektivy je nutné aby IT personál spolupracoval na vývoji Service Level Agreements (SLAs) spolu s byznysem. Je totiž velmi důležité zajistit, aby požadavky byly smysluplné a měřitelné. Planning to Implement Service Management (Plánování implementace správy služeb): Je již zmíněná kniha popisující praktické činnosti při plánování, implementaci a případné problémy a to nejen v případě zavádění správy služeb ITSM v rámci organizace. Co se týče implementace tak tento modul definuje jak by měla vypadat vize a zvolená strategie. Dále doporučuje základní koncept implementace ve fázích počínajících studií proveditelnosti a konče revizí implementovaných ITIL procesů. Během implementace je kladen důrazem na časové milníky, kritické faktory úspěchu a klíčové indikátory výkonnosti - Key Performance Indicators (KPIs). Po vlastní implementaci procesů musí být zaveden systém průběžného zlepšování procesů. Nesmí nastat situace, kdy po vlastní implementaci se o implementované procesy nebude nikdo starat. Takové procesy by se v průběhu vývoje organizace staly přinejmenším přítěží. Application Management (Správa aplikací): Je rozšířením Release Managementu1 se zaměřením na životní cyklus aplikace. Životní cyklus zde pokrývá fáze od samotného začátku tj. od výchozí potřeby byznysu až po konečnou fázi sunset tj. ukončení provozu aplikace. Základním úkolem na který se tento modul soustřeďuje je sladění projektů a IT strategie s projekty a strategiemi byznysu. Jinak řečeno je třeba mít strategii, vyvinutou společným úsilím IT a byznysu. Je však nutné dbát

1

http://www.itilsurvival.com/applicationmanagementitil.html

95

na to, aby tento soulad platil pro celý životní cyklus aplikace. V případě, že byznys požadavky nebudou respektovat IT strategii včetně projektů hrozí, že výsledná aplikace se ukáže jako nerealizovatelná, neodporovatelná, nespolehlivá nebo nedostatečně výkonná. V případě implementace takové aplikace výsledné problémy zatěžují Service Support. Pokud by se naopak upřednostňovala IT strategie může se lehce stát, že výsledná aplikace nebude odpovídat specifikacím byznysu. Security Management (Správa bezpečnosti): Popisuje procesy správy definované úrovně bezpečnosti týkající se primárně informací a dále pak služeb IT, infrastruktury a v neposlední řadě byznysu. Security Management je rozdělen do dvou částí. První částí je realizace bezpečnostních požadavků definovaných v SLA. Druhá část je realizace minimální úrovně bezpečnosti, která je nutná pro zaručení Business Continuity - kontinuity IT služeb. Součástí všech modulů obsažených v Security Managementu jsou aktivity posuzující rizika, možnou zranitelnost a dále pak správa a implementace protiopatření. Náklady na tyto protiopatření musí být vyčísleny a odsouhlaseny

byznysem.

Cílem

není

implementace

maximálních

opatření,

ale

implementace takových opatření, které jsou pro byznys dostatečné. Čili byznys většinou akceptuje určitou míru rizika tak aby výsledné řešení nebylo neúměrně drahé. ICT Infrastructure Management – ICTIM (Správa infrastruktury ICT) 1 Popisuje procesy, organizační aspekty a nástroje s cílem poskytovat stabilní technologickou a komunikační infrastrukturu. ICTIM se tak snaží dodávat pevný základ pro procesy definované v rámci ITIL Service Support a Service Delivery. Součástí ICTIM jsou návody pro konkrétní procesy řízení ICT infrastruktury jako např. : postup plánování, návrhu, implementace, následné aktivity technické podpory a řízení jednotlivých ICT komponent a souvisejících služeb. Řídící procesy ICT by měli být navrženy tak, aby primárně sledovaly zájmy a požadavky zákazníka. Současně ale musí být navrženy tak, aby došlo ke vzájemné shodě mezi zákaznickými požadavky a cenu kterou je zákazník ochoten za tyto služby zaplatit.

1

Zdroj: http://www.itil.cz/index.php?id=8

96

97