Scalanie rozproszone

Wdrożenie scentralizowanego systemu transakcyjnego ICBS firmy Fiserv miało wesprzeć zmiany biznesowe: wspomóc pracowników oddziałów w sprawnej i kompetentnej obsłudze klientów, ujednolicić zakres oferowanych produktów i procedury, obniżyć koszty wprowadzania zmian w ofercie. Oczywiście, wdrożenie systemu centralnego miało też obniżyć szeroko rozumiane koszty obsługi informatycznej banku. Oprócz ograniczenia zatrudnienia w oddziałach chodziło także o zmniejszenie komplikacji środowiska informatycznego, w tym zwłaszcza o zmniejszenie liczby aplikacji i interfejsów, co w efekcie miało obniżyć koszty związane z ich utrzymaniem. Chciano też uprościć zarządzanie firmową siecią i stacjami roboczymi.

Karawana jedzie dalej

Kiedy program B1 powoływano do życia, Bank Zachodni i Wielkopolski Bank Kredytowy stanowiły dwie niezależne organizacje, podobnej skali, lecz znacznie różniące się pod względem kultury biznesowej, zakresu informatyzacji i portfela produktowego. Połączenie obu banków wymagało uprzedniego, choćby zgrubnego, ujednolicenia w każdej z tych dziedzin. Z tego powodu będący właścicielem obu instytucji Allied Irish Bank (AIB) zdecydował, że każda z nich będzie wdrażać nowy system według własnej ścieżki, która ostatecznie doprowadzi je do pewnego poziomu zgodności. Dopiero wtedy banki miały połączyć się i przejść na wspólny system.

Scalanie rozproszone

BogusŁaw Sobala, zastępca dyrektora Departamentu ObsŁugi i Eksploatacji w BZ WBK, Wrocław

Stało się jednak inaczej. Kilka miesięcy po rozpoczęciu programu B1 - w listopadzie 2000 r. - zarząd AIB podjął decyzję o połączeniu obu banków w czerwcu 2001 r. W perspektywie przyspieszonej fuzji początkowa koncepcja wdrożenia musiała zostać zweryfikowana. Ostatecznie, zamiast wdrażać dwa oddzielne systemy ICBS, postanowiono od razu wdrożyć jeden, dodatkowo redukując liczbę interfejsów do aplikacji zewnętrznych. Po wybraniu systemu w obu bankach rozpoczął się wielki przegląd zasobów informatycznych, w wyniku którego projekty nie związane bezpośrednio z celami B1 lub fuzją zostały zarzucone, uwalniając zasoby do realizacji zadań priorytetowych. Efektem tego remanentu była także lista działań i projektów warunkujących sprawne przeprowadzenie projektu B1 i fuzji. Odbywające się w obu bankach projekty dotyczące podobnych zagadnień, choć w każdym z nich przebiegały inaczej, zaczęły być koordynowane przez jedną osobę. Chodziło o to, aby w zasadniczej fazie wdrożenia nie pojawiły się niespodzianki.

Czerwone, żółte, zielone

Gdyby wyzwanie stojące przed kierownictwem projektu B1 chcieć określić jako "trudne", nie oddałoby to jego rzeczywistej wagi. Synchronizacja - w czasie i co do zakresu - kilkudziesięciu prowadzonych jednocześnie projektów przygotowawczych w różnych dziedzinach merytorycznych, a później także projektów w ramach samego programu B1 - biorąc pod uwagę ograniczenia czasowe - graniczyła z niewykonalnością. Tu z pomocą przyszedł właściciel oraz uczestnicząca w projekcie w roli doradcy firma Accenture. Połączenie wypracowanych przez nie metodyk zarządzania zmianami i prowadzenia projektów zaowocowało opracowaniem dla programu B1 jednej, spójnej metodyki ICJ (Integrated Change Journey - zintegrowana ścieżka mian), która jest obecnie wykorzystywana także w innych projektach prowadzonych w BZ WBK.

Metodyka ICJ dzieli wdrożenie na trzy równoległe strumienie działań. Strumień pierwszy obejmuje koncepcję wdrożenia: opracowanie założeń biznesowych, przełożenie ich na szczegółowe wymagania funkcjonalne, opisanie i przygotowanie interfejsów do systemów zewnętrznych itd. Strumień drugi to podejmowane równolegle działania przygotowawcze, dostosowawcze i uzupełniające, pozwalające na wdrożenie systemu zgodnie z wymaganiami określanymi w ramach strumienia pierwszego. Strumień trzeci to działania kontrolne, sprawdzające zgodność dwóch poprzednich strumieni z ich własnymi harmonogramami, oraz dodatkowo wspomaganie zmian organizacyjnych potrzebnych do sprawnej realizacji każdego z nich. Jego "właścicielem" był Departament Zarządzania Zmianami.


TOP 200