Pro každou finanční organizaci je provozní systém v dnešní době nutností. Takový systém musí bezpodmínečně pokrývat běžné provozní agendy a zároveň musí být dostatečně flexibilní a upravitelný tak, aby bylo možné operativně a v krátkém čase rozšířit jeho funkcionality o pokrytí nových agend či produktů. Alternativní cestou je situace, kdy banka provozuje pro každou svoji agendu specializovaný software napojený na určitou „centrální aplikaci“.

V současnosti se v českých bankách (a také družstevních záložnách) vyskytují oba případy – jak subjekty pracující s jedním primárním provozním systémem pokrývajícím podstatnou většinu jejich agend, tak subjekty s heterogenním prostředím více či méně propojených aplikací od více dodavatelů, které jsou de facto řízeny z jedné hlavní aplikace. V obou těchto případech je velmi důležité proces implementace takového provozního systému nepodcenit. Na první pohled by se mohlo zdát, že nasazení provozního systému je řádově snazší v prvním případě. Nemusí to být pravidlem a vždy velmi záleží na zkušenostech a spolupráci týmu banky a týmu dodavatele, který implementaci realizuje. Každý takový projekt sice ve své podstatě vyžaduje obdobné kroky, liší se ale například délkou implementace, rozsahem prováděných prací a v neposlední řadě počtem implementovaných komunikačních rozhraní.

Implementační fáze

Mezi důležité kroky implementačního projektu patří analýza a následná realizace parametrizace a změn systému. Každý subjekt je jiný, každý má své vlastní, různě složité procesy a na ty je potřeba systém připravit. Samozřejmě, obecný základ core bankovního systému má každý dodavatel již předem připravený (nebo by alespoň měl mít). Nicméně vždy se najde poměrně široký rozsah specifických zákaznických požadavků, na které je třeba reagovat změnami ve stávajícím řešení a mnohé speciální funkcionality je třeba programovat zcela nově.

Před implementací tak dochází k diskusím nad systémem a business procesy banky a výsledky těchto analytických diskusí jsou následně promítnuty ve vzájemně odsouhlasené studii řešení. Například v naší společnosti je realizace změn řízena metodikou RUP pocházející ze společnosti IBM. S použitím této metodiky je oboustranně zajištěno, že budou minimalizovány nežádoucí provozní stavy, které zákazník buď předem nepředpokládal, nebo mu z různých důvodů nevyhovují.

V dalším kroku se dodavatel systému ve spolupráci s bankou zaměří na technické prostředí, ve kterém bude nový systém pracovat. To zahrnuje opět diskuse, návrhy, studie a následnou realizaci. Dobrým zvykem u každé implementace bývá také proces předání hotového řešení a testovací provoz. V naší společnosti tomuto kroku říkáme akceptační řízení. To probíhá formou jednotlivých iterací (obvykle dvě až tři kola), ve kterých banka ve zkušebním provozu testuje nový systém (pro účely akceptačního řízení se také obvykle připravuje seznam testovacích scénářů), dolaďují se případné nedokonalosti a opravují nalezené chyby. Po ukončení akceptačního řízení následuje přechod do plného provozu. V případě, že k implementaci přistupujeme jako k projektu, je vhodné se opřít o některou standardní mezinárodně uznávanou metodiku, jako PMI nebo IPMA.

Různé typy bank, různě náročné projekty

Pokud jde o implementaci v různých typech bank, je samozřejmě nejjednodušší situace v případě zcela nové banky. A to z prostého důvodu – nedochází ke změně systému, a dodavatel se tak nesetkává se záležitostmi jako migrace dat, přeškolení zaměstnanců na nový systém atd. V každém případě i nová banka má v okamžiku spuštění implementace systému již jasně definované procesy (byť v daném okamžiku třeba jen formálně „na papíře“).

Pokud pak dochází v případě již existující banky k výměně celého core bankovního systému, setkáváme se téměř vždy se specifickými situacemi, které je nutné řešit individuálním přístupem. Mezi ty nejzásadnější specifika patří respektování již fungujících procesů. Většinou se banka rozhodne změnit svůj systém z důvodů nedostatečné funkčnosti, nemožnosti rozšiřování, nákladnosti provozu apod. V žádném případě však nelze očekávat, že se procesy v bankách přizpůsobí informačnímu systému.

Dalším specifikem je migrace dat. V závislosti na délce používání předchozího systému a počtu klientů banky může být objem přenášených dat různě velký, a tedy i různě náročný (můžeme se dokonce setkat s migrací až jednoho milionu aktivních klientských smluv). Naše ověřené postupy v rámci migrace dat počítají s analýzou těchto dat coby prvním krokem tohoto implementačního subprojektu. Je také potřeba adekvátně vyřešit a připravit „přenosový můstek“ mezi starým a novým systémem a data věcně zkontrolovat, opravit a přenést. Posledním krokem je kontrola přenesených dat v novém systému. Všechny tyto kroky vypadají na první pohled velmi jednoduše, avšak ve skutečnosti je to souhrn poměrně náročných činností.

Velmi důležitým specifikem implementace core bankovního systému jsou samotní zaměstnanci banky a jejich zvyklosti na práci se stávajícím systémem. Nejen, že určitá část zaměstnanců se změnou systému nesouhlasí, ale i u těch, kteří změnu považují za potřebnou, se často setkáváme s pasivním přístupem, někdy hraničícím až se starým pořekadlem „starého psa novým kouskům nenaučíš“. A tak i zdánlivě banální krok, jakým je přeškolení zaměstnanců na nový systém, je často klíčovým bodem pro úspěšně uzavřený projekt implementace.

S podobnými kroky a specifiky se dodavatel setkává také u banky, jejíž ICT infrastruktura funguje na bázi jedné řídicí aplikace, do které jsou napojeny různé systémy pro dílčí agendy banky. Může se jednat o subsystémy řešící CRM, data warehouse, front office, messaging, finanční účetnictví atd. Do již tak komplikované struktury se má napojit nový systém, ať už v roli hlavního provozního, nebo dílčího systému pro konkrétní agendu. Kroky uvedené v předchozí části tohoto textu jsou pak mnohem složitější a tyto implementace bezesporu patří k těm nejnáročnějším. Vysoké nároky jsou kladeny především na analytickou část projektu, standardně zahrnující celou řadu diskusí a mítinků, ve které je třeba popsat vytvořená propojení s jednotlivými částmi takové infrastruktury.

Samostatnou kapitolu pak tvoří implementace pouze části kompletního provozního systému. V dnešní době je většina core bankovních systémů postavena na modulární architektuře, která umožňuje implementovat nejen systém jako celek, ale také pouze určitou část pokrývající jen nějakou dílčí agendu banky. Takto je možné implementovat například řešení pro internetové bankovnictví, platební styk, agendu úvěrových produktů, podporu obchodní sítě atd. U těchto dílčích oblastí a modulů systému jsou implementační kroky velmi podobné, nicméně časově i pracně méně náročné.

IT musí podporovat rozvoj byznysu

Schopnost bank inovovat svoji nabídku produktů a služeb na základě signálů z trhu je dnes do značné míry závislá na informačních technologiích. Za úspěšnou implementaci lze přitom považovat jen takovou, které se podařilo nový systém zprovoznit se všemi funkcionalitami, v termínech, které zákazník vyžadoval, pří které se případně data správně přenesla a také zaměstnanci banky umí s novým systémem bez obtíží samostatně pracovat. A samozřejmě, úspěšná implementace je taková, která bance přinese nové klienty nebo zlepší péči o ty stávající.

Zbyněk Potrusil, Tomáš Halva
Autoři působí ve společnosti TurboConsult, která vyvíjí provozní informační systémy pro banky, družstevní záložny a další finanční instituce.