Firmy si dnes nedovedou svoji práci představit bez dobře fungujících komunikačních a informačních technologií. Na nich totiž často závisí konkurenční výhoda dané firmy a také úspěšnost každé společnosti. V oblasti IT dochází v dnešní době k nebývalému rozmachu, proto je nezbytné neustále zavádět do informačních systémů a technologií podniků nejrůznější inovace a zároveň umět dané změny řídit. Platí to v každém oboru, avšak v oboru bankovnictví dvojnásob.


Bankovnictví bylo známo svojí konzervativností. V současné době tomu tak již není. Klienti neusilují o to, aby mohli být zákazníky určité banky, ale naopak banky o své klienty samy bojují. Aby si banky získaly a udržely své klienty, musejí neustále inovovat bankovní služby, které poskytují. A právě inovace je jedním z prostředků umožňujícím bankám získávat nové a nové klienty a udržovat si ty stávající.

Každá inovace však znamená zásahy do stávajících informačních systémů. Je třeba si uvědomit, že ne všechny změny probíhají bez problémů. Vlivem velkého počtu požadavků na změny jsou pracovníci IT útvarů v bance pod obrovským tlakem, který neustále vzrůstá. Jsou doslova zaplaveni množstvím požadavků, které mají různé priority, různé dopady a jejichž řešení může být finančně náročné. Aby IT v bance obstálo, je potřeba zavést systematický postup pro řízení změn, naučit se jednotlivé změny třídit, rychle a efektivně na ně reagovat.

Při realizaci změnového řízení je třeba dodržovat následující zásady:

. požadavky na změny musejí do IT přicházet prostřednictvím jednoho kanálu, který je společný pro všechny zúčastněné, jedině tak budou mít o změně a jejím průběhu přehled všichni,

. všechny změny musejí být měřitelné tak, abychom byli schopni je řídit,

. za správu požadavků na změny a řízení jejich životního cyklu musí být odpovědná jedna autorita, obvykle to bývá HelpDesk.

Typický životní cyklus požadavku na změnu začíná už v okamžiku, kdy uživatel vznese daný požadavek k odpovědné autoritě (HelpDesk), ta jej na základě vlastností požadavků klasifikuje a určí způsob, jak bude řešen.

Fáze vyhodnocení požadavku se účastní několik odpovědných osob. Metodický gestor, jenž odpovídá na otázku, zda je požadavek v souladu s business. Gestor spolupracuje s garantem aplikace/oblasti, který se zabývá skutečností, je-li požadavek v souladu s architekturou. HelpDesk pak odpovídá na to, v jakém stavu se požadavek nachází, určuje osoby odpovědné za řešení požadavku, stanovuje plán řešení a náklady na změnu.
 

Existují dvě možné cesty vyřízení požadavku na změnu:

. Operativní - požadavky jsou vyřizovány postupně jeden po druhém, touto cestou jsou řešeny hlavně požadavky na servis a provoz systému, například požadavek na vygenerování reportu či opravení chyby v aplikaci, která nesnese odkladu,

. Projektová - související požadavky se neřeší ihned, ale jsou seskupovány do tzv. releasů a řeší se jako jeden projekt.

Problém, který řeší většina bank v současné době je realizace velké části požadavků v operativní větvi. Tento způsob přináší řadu nevýhod, zejména nemožnost řešit požadavky v kontextu souvisejících požadavků. Může se stát, že na HelpDesk přijde požadavek na změnu jedné komponenty. Hrozí ovšem nebezpečí, že za krátký čas přijme HelpDesk další požadavek, který bude řešit další změnu stejné komponenty, jež je v rozporu s prvním požadavkem. V součtu je řešení operativní cestou nákladnější a nelze jej koordinovat. Důsledkem může být, že rozvoj informačních systémů připomíná rakovinové bujení, nikoliv řízenou evoluci. Proto by mělo být snahou každého ICT útvaru seskupovat maximální počet stejnorodých požadavků do předem plánovaných releasů a řešit je jako projekt. Projektová cesta bývá nákladově výhodnější, ale zabraňuje nekoordinovanému rozvoji systému bez respektování jakékoliv koncepce.

S řešením požadavků na změnu souvisí i tzv. eskalační proces. Jedná se o proces řešení konfliktů v rámci projektů i mezi nimi. Obvykle mívá několik úrovní. Z našich praktických zkušeností lze doporučit v rámci projektů jednu eskalační úroveň (touto autoritou bývá řídící komise projektu) a pouze jednu úroveň meziprojektovou (typicky výbor pro automatizaci). Pokud existuje více úrovní, pak eskalační proces bývá obtížně průchozí, což má za následek zpomalení procesů změnového řízení. Lze tedy konstatovat, že nefunguje-li eskalační proces, pak nefunguje ani změnové řízení.

Projekt Hejrup v Komerční bance
V roce 2000 realizovala společnost Unicorn projekt Hejrup v Komerční bance. Součástí projektu byla optimalizace procesu změnového řízení v útvaru aplikačního vývoje KB.

Před zahájením tohoto projektu nebyl aktuální stav procesů dostatečně průchozí a nezaručoval systematický přístup - zadavatelé požadavků přímo kontaktovali osoby odpovědné za realizaci požadavku. Změny tudíž probíhaly nekoordinovaně, docházelo k nekoordinovanému nasazování nových verzí a celý proces nebyl měřitelný. Management útvaru proto mohl obtížně monitorovat takový proces a účtovat náklady zákaznickým útvarům.

Během realizace projektu došlo k revizi struktury evidovaných údajů o požadavcích. Na základě této struktury byly definovány čtyři kategorie požadavků. Dvě kategorie požadavků využívají operativní cesty (provoz, operativní řešení chyb) a zbývající dvě kategorie řeší požadavky projektovou cestou (projekty vzniklé na základě plánovaných pravidelných releasů, projekty vznikající jako důsledek řešení významných změn). Následně byl vydefinován pro projektovou cestu způsob vzniku projektů, principy a metodika řízení projektů.

Pozn. red.: Autor článku, Radovan Jirka, působí jako ředitel společnosti Unicorn Consulting.