Publikováno: 20. 10. 2006
Terminologie týkající se procesu Change management. Zajímá mne, jak správně dle ITIL označit aktivitu (v češtině, angličtině), kterou jsou řízeny změny, kterě upravují již existující (zaregistrované) změny uživatelů (tzv. RFCs). Příkladně – po přijetí požadavku ke změně (RFC) je uživatelem požadováno doplnění nebo změna původní změny (RFC).V souvislosti s výše uvedeným procesem mne zajímá i termín (český, anglický) odpovídající jednotlivé změně již existující změny. A poslední dotaz – jaký je vztah mezi ITIL disciplínami Change management a Applications Management?.
ODPOVĚĎ
ITILovský proces Change Management neobsahuje žádné zvláštní aktivity pro řízení těch RFCs, které nějak doplňují, rozšiřují nebo mění obsah jiných RFCs. Rovněž pro tyto doplňující nebo pozměňující RFCs neexistuje v ITIL specifický název. Není to však nějaká procesní nebo terminologická nedomyšlenost ani nedostatek v ITIL, ale právě naopak. Pokud bychom totiž chtěli klasifikovat RFCs podle toho, jak spolu vzájemně souvisejí, a vytvářet speciální procesní aktivity pro řízení “pozměňujících” RFCs, nutně bychom se dostali do nemalých obtíží, neboť možností a variant, které by mohly nastat, by bylo nespočetně. Mimo jiné by zřejmě bylo nutné rozlišovat, v jaké fázi životního cyklu se nachází původní RFC, a pak pravděpodobně pro každou jednotlivou fázi stanovit pravidla a kriteria přípustnosti dodatečné změny. Rovněž je třeba mít na paměti, že všichni předkladatelé RFCs nebudou mít nikdy dokonalý přehled o obsahu všech podaných RFCs a tudíž nelze očekávat, že sami předkladatelé by byli na 100% schopni při podání RFC rozlišovat mezi prvotním a pozměňujícím RFC, a tudíž by stejně bylo nutné posuzovat každý jednotlivý RFC i z toho pohledu, zda se nedotýká nějakého jiného již podaného RFC. Jak jsou tedy v procesu Change Managementu tyto “pozměňující” RFCs řízeny? Úplně stejně jako každý jiný RFC. To, že se jedná o RFC pozměňující jiný RFC, je identifikováno nejpozději v rámci aktivity “Impact and resource assessment”, jejímž obsahem je posouzení RFC ze všech možných hledisek (technického, organizačně-procesního, finančního, obchodně-provozního). Samozřejmě, že k tomu může dojít i dříve – často se tak stane hned při vložení nově podaného RFC do nástroje pro řízení změn, kdy po vyplnění základních atributů může být souvislost s jiným RFC zřejmá na první pohled, např. když se dvě RFCs budou týkat stejné konfigurační položky. Kromě toho jeden z atributů záznamu RFC je i vícečetný atribut “související RFCs”, a tudíž nelze vyloučit, že již předkladatel RFC tento atribut vyplní (ale jak již bylo řečeno, nelze se spoléhat na to, že pokud tak neučiní, nemůže mít tento RFC souvislost s jiným, již podaným RFC). Nicméně podstatné a zásadní je to, že posouzení toho, jak s takovýmto “pozměňujícím” RFC bude naloženo, bude provedeno právě v již zmíněné aktivitě “Impact and resource assessment”, kde budou posouzeny i možnosti realizovatelnosti pozměňujícího RFC ve vazbě na to, v jaké fázi realizace se nachází původní RFC atd.
Vše výše uvedené však nemusí platit pro situaci, kdy kromě procesu Change Management existuje v IT organizaci i process Release Management a kdy jsou pro jednotlivé části ICT infrastruktury (obvykle pro jednotlivé ICT systémy nebo ICT služby) stanovena pravidla jejich verzování, a to v dokumentu, který se jmenuje Release Policy. Existence tohoto dokumentu totiž velice usnadňuje organizaci celého změnového řízení, a to včetně řízení RFCs, které se vzájemně doplňují, vylučují nebo pozměňují. V Release Policy je totiž obvykle pro jednotlivé ICT systémy, resp. služby, stanoveno, jaké změny a v jakých termínech je dovoleno předkládat, a zejména kdy je dead line pro příjem RFCs, které mají být realizovány v následujícím releasu. Všechny RFCs jsou tedy pak posuzovány společně, a to ve všech vzájemných souvislostech, a případné dodatečné podání RFC, jenž by modifikoval obsah již uzavřeného release (tzn. release, jehož realizace již započala), je v Release Policy buďto výslovně zakázáno a nebo jsou zde uvedena kritéria, za nichž může být dodatečný RFC do již uzavřeného release zařazen, resp. kdo je oprávněn o tom rozhodnout.
Poslední část Vašeho dotazu se týká vzájemného vztahu procesu Change Management a disciplíny Application Management (v pojetí ITIL). Change Management je procesem z oblasti podpory služeb (service support), zatímco Application Management je disciplínou popisující zásady řízení životního cyklu aplikačního programového vybavení, a to od prvotního sběru požadavků na jeho funkcionalitu, přes vývoj, dodávku, provozní podporu, až po stažení z používání. Z tohoto pohledu je tedy proces Change Management využíván Application Managementem pro řízení upgrade aplikací, které jsou již nasazeny v produkčním prostředí. Samozřejmě, že tyto aplikační upgrade nejsou jediným obsahem RFCs – proces Change Management řídí a koordinuje operativní změny všech komponent produkční infrastruktury. Nicméně existence Change Managementu je pro oblast řízení životního cyklu aplikačního portfolia (tj. pro Application Management) důležitá a přínosná v tom, že si nemusí pro provozní upgrade aplikací designovat vlastní separátní proces. Pro úplnost je třeba podotknout, že v praxi se někdy ze strany aplikačních správců takové snahy objevují, tj. snahy o zavádění paralelních procesů a odlišných schvalovacích mechanismů pro aplikační upgrade. Tento přístup však není v souladu s ITIL, a rovněž i dodržení požadavků normy ISO/IEC 20000 je v těchto případech mírně problematické.
Štítky: Jiří Skála
Autor:: Kateřina Mrkvičková