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

Transkript

1 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: Ing. Václav Šebek, CSc. Praha duben, 2010

2 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Praze dne: Radomír Bohuslav

3 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.

4 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.

5 Obsah 1 Procesně řízený podnik Funkční organizace Procesní organizace Procesní struktura DHL IT Services Change management dle ITIL Information Technology Infrastructure Library (ITIL) Information Technology Infrastructure Library V Dodávka služeb (Service Delivery) Podpora služeb (Service Support) Od ITIL k ITIL V ITIL Change management Oblasti aplikace Příčiny vzniku Změn Change management a okolní procesy Druhy a klíčové elementy RFC Change management proces dle ITIL Change management v datovém centru Základní Change management proces Change initiation Kategorizace změn podle rozsahu Kategorizace Změn podle úrovně rizika Kategorizace změn podle jejich priority Workflow a rozdělení zodpovědností Change Impact Analysis & Risk Workflow a rozdělení zodpovědností Change Review & Approval Workflow a rozdělení zodpovědností Create Change Package Rozdělení zodpovědností Change package Workflow a rozdělení zodpovědností Implement Change Workflow a rozdělení zodpovědností Review Change and Close Workflow a rozdělení zodpovědností Týdenní cyklus zpracování Změn Urgent a Emergency proces Nedostatky implementace Co je implementováno podle ITIL Týdenní zpracování Změn Emergency Restoration Report Pozdě příchozí Změny Change management proces vs. zákazník Nástroje pro implementaci Nástroj HPSD

6 Specifikace požadavků na nový systém Migrace HPSD na Service Manager Nástroj IQG manager Budoucnost IQG4You Online SBF Propojení SBF a CMDB Závěr Seznamy použitých zdrojů Seznam zkratek Slovík důležitých pojmů Seznam obrázků Seznam tabulek Seznam grafů Přílohy

7 Ú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

8 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ů takto 1 : 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 8

9 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. Výhody Nevý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ínky 2 : 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. 9

10 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 Nevýhody Tabulka 2. Výhody a nevýhody procesního řízení 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

11 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 a projektovou metodologii PRINCE2 2. 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 CMMI 3 úrovně 4. 1 První mezinárodní standard IT Service managementu. Více viz. 2 Více viz. 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. 11

12 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 Managementu 1 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ěnu 2 (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 Detailnější struktura Service Control Managementu je součástí přílohy (1) 2 Změna předmět Change managementu je dále v označována velkým počátečním písmene. 12

13 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í (ICT 1 ), ICT infrastruktury a řízení služeb IT (ITSM 2 ). 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 ICT - Information and Communication Technology 2 ITSM - Information Technology Service Management 13

14 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íky 1 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 Commerce 2, 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 Zásadní podíl na rozvoji ITILu má nezisková organizace itsmf Česká odnož

15 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 ITIL 1 : 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 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: 15

16 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 itsmf 2 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ů 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 Zdroj: Úvodní přehled ITIL, Copyright itsmf, 2004 [3] 2 Zdroj: Úvodní přehled ITIL, Copyright itsmf, 2004 [3] 16

17 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 zranitelná místa jsou ošetřena. maximálně redukovány a případná 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 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 (SPOC 1 ) mezi 1 Single Point Of Contact 17

18 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í management 1 (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é CMDB 2. 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 Error 3 ). 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í 2 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.. 18

19 identifikaci a řešení problémů a známých chyb ještě předtím, než incidenty. nastanou 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, Workarounds 1. 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. Řízení Změn dále jako Change Management je věnována kapitola 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

20 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

21 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: 21

22 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ěn 1, 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ého 2. 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ých 3 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

23 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 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 produkčních systémů, vztahující se k podpoře či údržbě 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

24 právě vyvíjených CIs v rámci některého z projektů, zpracovávány (kontrolovány) pomocí Change management procesu 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 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

25 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] 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

26 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 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

27 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ího 1 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

28 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ům 1 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

29 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 CIO 1 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 Finanční souhlas Náklady na Změnu odpovídají stanovené výši nákladů. Technický souhlas Změna je realizovatelná, má smysl a neobsahuje nežádoucí dopad na IT služby. Byznys souhlas Změna je chtěná byznysem a byznys rovněž akceptuje dopad Změny 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 2 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. 29

30 připravit back-out 1 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 up 2 ) aktivity. Jakékoliv zjištěné nesrovnalosti by měly být reportovány CAB komisi. 1 Back-out nebo také roll-back 2 Zpětné zjišťování a vyhodnocování 30

31 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

32 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 DPWN 1 ). 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 2 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. 32

33 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 box 1, 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

34 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ích 1 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 callu 4, 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) 2 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ů. 34

35 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 pole 1 čí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ě u). 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

36 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

37 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 management 1 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

38 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

39 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í 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 Change 39

40 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 SAN 1 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

41 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í. Tabulka 5. Kategorizace změn podle úrovně rizika RFC kategorie 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 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

42 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 může být odstranění poruchy HW, instalace kritického patche 1 nebo instalace bug fixu apod. Změny s touto prioritou podléhají emergency Change management procesu ( viz. kapitola 3.9) Zdroj: Vlastní tvorba 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

43 Obrázek 14. Change initiation fáze Start Change initiation Requestor vytvoří RFC požadavek v HPSD Pre-autorised Akceptace RFC Revize RFC (kategorizace) Je správně ohodnoceno riziko a priorita? ANO NE Vrácení requestorovi na doplnění Routine/Relase? Routine Start Create Change Package Release Change Manager/Analytik Konec Change initiation Odmítnutí 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

44 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

45 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 Povinná sada WO: Zdroj: Vlastní tvorba (DHL HPSD) 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

46 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

47 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

48 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

49 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 model 1 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 standardy 2. 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ému 3 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. 2 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í 49

50 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 Složení CAB komise: Zdroj: Vlastní tvorba (DHL HPSD) 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

51 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 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

52 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

53 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 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. Priorita Emergency Urgent High Medium Low Tabulka 7. Rozdělení zodpovědností Typ RFC Release Routine Minor Preauthorized TIL TIL / CM CM Zdroj: Vlastní tvorba Definováno v Request katalogu 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

54 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 RFC 1. 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

55 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

56 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 Server Hostname(s) or CI name(s) Changed components and associated downtime Service Name SERVER Downtime 1 czchols1509 SAP CAR - NW EP 7.0 PROD no no SERVICE Description/Note 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

57 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) Task The change implementation takes longer than 1 day so exceeds the Sunday change window Start Time (PRG time) End Time (PRG time) Additional comments/justificatio n Who (HP Service Desk Workgroup) 1 2 czchols czchols czchols1510 Day 1 ITS Bulletin + sent (Start of RTP) Stop the running Deltas relevant to Repository 3 Make sure that SFTP script for countries of initial load is deactivated. No transfer of initially loaded data to ESB until verified by countries. Switch OFF OVO monitoring on BODS server (czchols1510) After executing this step, inform by to David Kucera & Michal Plandor (EMEA-SAP.BASIS) Zdroj: DHL ITS, vlastní úprava 16:30 16:45 16:30 16:45 16:30 16:45 EMEA-SAP.COC.SUPPORT (SAP CAR Service Owner) EMEA-SAP.COC.SUPPORT (BODS Technicians) EMEA-SAP.COC.SUPPORT (Basis Technician) 17:00 17:15 EMEA-SHIFT.SYSADMIN RTP plán, IQG checklist a komunikační plán 1 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

58 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í hosting 2 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 Topaz 3 SiteScope 4 monitoring. nebo 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

59 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

60 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 Typ RFC Release Routine Minor Preauthorized Emergency SM + Urgent CAB + EC SM + EC Urgent SM + Urgent CAB + IQG SM + IQG nebo EC High Medium SM + CAB + IQG SM + IQG Low Zdroj: Vlastní tvorba CM Definováno v Request katalogu 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

61 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 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

62 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í ové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

63 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

64 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 1 party týmů a komunikuje se zástupci byznysu 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 3 rd party jsou externí (mimo DHL) týmy, konzultanti, dodavatelé atd. 64

65 Organizace a vedení GO / NO GO 1 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 em 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 hypercare 2 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

66 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 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, Zavření RFC, status je změněn na Closed (RFC je dále archivována v HPSD). 3.8 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

67 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 Vývoj a příprava řešení (TAT,UAT) IQG meeting PÁ SO NE PO ÚT ST ČT PÁ SO NE Requestor RTP plán IQG checklist Reboot intrukce Splnění IQG podmínek Change analyst Implementační Manager Vytvoření IQG WO RTP meeting IQG minutes Vytvoření implement. WOs Implementer 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

68 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 window 1. 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 emergency 2. 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 Downtime window je podstatný parametr služby zaznamenaný v support modelu a SLA. 2 Emergency je označení využívané ve firmě DHL ITS pro urgentní změny tak jak je definuje ITIL V2 68

69 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í u 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

70 Tabulka 11. Popis emergency a urgent procesů Části CM procesu EMERGENCY URGENT Create Change Request Change Initiation 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) 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 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 IA/RA fáze Neaplikuje se Neaplikuje se Change Review and Neaplikuje se Urgentní souhlas CAB komise (CAB Approval (CAB) approval) je zajištěn Change managementem pomocí u. Pouze Change manager nebo jeho zástupcem je oprávněn zahájit tento proces. Create Change Není rozdíl Není rozdíl Package Schválení implementace Změny IQG WO Requestor musí sám proaktivně kontaktovat skupiny schvalující IQG workordery. Requestor musí sám proaktivně kontaktovat skupiny schvalující IQG workordery. Schválení IQG komisí (Approval to Implement) Change Manager schvaluje Minor Emergency Změny Emergency komise (EC) schvaluje Significant nebo Major Emergency Změny 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 Implementace Změny Není rozdíl Není rozdíl Vyhodnocení a Emergency Změny odsouhlasené Není rozdíl uzavření Změny Change Managerem a EC jsou prezentovány na následujícím IQG meetingu Zdroj: Vlastní tvorba 70

71 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

72 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

73 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

74 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 PdS 1 (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

75 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í Počet Změn za týden týden Schálené minor Změny Schálené significant Změny Schálené migrační změy Globalní změny Emergency Změny Urgentní Změny 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žeb 1. 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

76 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 % % % 18 % % % 37 % % % 23 % Celkový počet Změn 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] 0 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

77 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ž 10 1 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 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 dny IARA, 3 dny CAB a 5 dní IQG fáze 2 Špatná dokumentace, testování, implementační plán, předchozí propagace upozornění na Změnu 77

78 Graf 3. Pozdě příchozí Změny rozdíl CAB/RTP Pozdě 41% 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. Včas 59% Graf 4. Pozdě příchozí Změny rozdíl SO/CAB 13% 1 týden 37% 5% 3% 3% 2 týdny 3 týdny 1 měsíc 2 měsíce 3 měsíce 10% 6 měsíc 1 rok 5% > rok 4% 8% 12% 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

79 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

80 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

81 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 Této verzi končí oficiální podpora ze strany HP koncem roku 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: 81

82 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

83 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 file 2 databázi využívanou SM7. To v konkrétním případě aplikace CLOB 3, BLOB 4 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-based 5 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 2 Je relativně jednoduchý databázový system, který uchovává každou databázi ve formě jednoduché tabulky vice viz. 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 83

84 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