Pierwszy system zachodni

Na ścieżkę wyboru takiego rozwiązania jako pierwszy wkroczył Bank Śląski, wybierając system ICBS firmy Fiserv działający na platformie AS/400. System ten był rozwinięciem wcześniejszego systemu CBS - pracującego w architekturze terminalowej - do systemu w architekturze klient-serwer. Rolę aplikacji klienta pełniła aplikacja PS Teller. Nie był to więc system nowy, lecz stanowił kolejny etap ewolucji systemu działającego w znacznie mniejszej skali. Użycie tego rozwiązania do obsługi dużego - jak na polskie warunki - banku wymagało daleko idącej jego naturalizacji i prac optymalizacyjnych, zwłaszcza w zakresie tzw. przetwarzania dnia, które często zachodziło też w godzinach porannych, gdy bank powinien już być otwarty do obsługi transakcyjnej klientów.

Z tego względu rozwiązania wybranego przez Bank Śląski nie można było zaliczyć do systemów typu 24/7. Na owe czasy stanowił on jednak rewolucję w standardzie obsługi bankowej i umożliwiał uzyskanie znaczącej przewagi technologicznej. Odrębne pytanie, czy należycie wykorzystanej? Trzeba jednak wspomnieć, że system nie obsługiwał operacji typu centralowego i wymagał uzupełnienia go inną aplikacją. Rolę tej aplikacji przejściowo pełnił system PABA firmy Actis, a docelowo MIDAS, produkt renomowanej firmy angielskiej. Poważnym problemem związanym z zastosowaniem systemu Fiserv w Banku Śląskim stało się dostosowanie go do obsługi dużego wolumenu rachunków. Aplikacja ta była bowiem jednowątkowa i bez zasadniczej przebudowy jej architektury - a być może napisania jądra systemu od nowa - nie dało się w prosty sposób zwiększyć jej zdolności przetwarzania.

Kolejne przykłady

Drugim bankiem, który rozpoczął wdrożenie zachodniego systemu centralnego, był Bank Przemysłowo-Handlowy z Krakowa. Wybrał on system Profile firmy Sanchez, poddając go również bardzo głębokiej modyfikacji. Nieco później system ten został wybrany również przez Powszechny Bank Kredytowy z Warszawy, który dokonał wdrożenia tego samego systemu, ale w wyższej wersji. Zrządzeniem losu, a właściwie decyzją zagranicznych akcjonariuszy obu banków doszło do ich połączenia, czego wynikiem stała się konieczność połączenia obu baz. Doszło tu do dosyć osobliwego zjawiska, jakim był downgrade, czyli dostosowanie systemu wypadkowego do niższej wersji systemu Profile. System ten był również wybrany przez Kredyt Bank i zaimplementowany po ok. pięciu latach od momentu rozpoczęcia projektu. Z istotnych wydarzeń na rynku polskim, które miały miejsce w ostatnich latach, warto wspomnieć o połączeniu Wielkopolskiego Banku Kredytowego w Poznaniu i Banku Zachodniego we Wrocławiu, co w efekcie przyniosło konwersję z systemu Bankmaster firmy Kindley na system Fiserv implementowany właśnie w Banku Zachodnim po jego przejęciu - w wyniku procesów prywatyzacyjnych - przez głównego akcjonariusza WBK.

Odrębną historię tworzy bank Pekao, kolejny już rok prowadząc implementację systemu Systematix firmy Altell. W przypadku tego banku łączny czas implementacji systemu z pewnością przekroczy magiczną barierę pięciu lat. Jednak w tym przypadku może to usprawiedliwiać jego wielkość i fakt, że była to pierwsza - i prawdopodobnie ostatnia - naturalizacja tego systemu w Polsce.

Ze wszystkich zebranych doświadczeń z wdrożeń zachodnich systemów w Polsce jedno wynika niezbicie - naturalizacja takiego systemu jest bardzo złożona i pracochłonna, co prowadzi czasem do utraty optymalności jej działania.

Pojawiają się problemy z wydajnością. Proces ich implementacji, wymagający często wsparcia firm zachodnich, jest bardzo kosztowny, a polskie banki bardzo niechętnie przyjmują koncepcję wdrożeń opartą na pełnym przyjęciu funkcjonalności zawartej w wersji podstawowej. Nie wydaje się to zresztą możliwe do przyjęcia dla banków mających już historię produktową, której nie sposób przecież przerwać w momencie implementacji nowego systemu.

Dla Computerworld komentuje

Wiesław Frydrych, dyrektor generalny sektora bankowego w ComputerLand SA

Szanse wypromowania polskiego rozwiązania scentralizowanego dla polskich banków są znikome, żeby nie powiedzieć - równe zeru. Współczesny system scentralizowany jest rozwiązaniem wielowarstwowym, z relacyjną bazą danych, skalowany od setek tysięcy do dziesiątków i setek milionów rachunków. Musi mieć również możliwość wdrożenia na różnych platformach systemowych - od mainframe, przez Unix, do Linux i Windows. Oznacza to również dopasowanie do zróżnicowanej przepustowości sieci. Stworzenie systemu pokrywającego funkcjonalnością działalność detaliczną, korporacyjną i koniecznie departamentu skarbu wymaga inwestycji kilkunastu milionów dolarów rocznie przez ok. 5 lat, a co ważniejsze - banku, który zgodziłby, aby być poligonem doświadczalnym. Wydaje się, że nie ma takiego banku. Dodatkowo jedynie pierwszą dwudziestkę banków - biorąc pod uwagę przynoszone przez nie zyski - stać na to, aby sfinansować taki projekt. Pewien potencjał stanowią zrzeszenia banków spółdzielczych i SKOK. Trendy na świecie wskazują jednak, że małe banki coraz częściej korzystają z oferty outsourcingu lub w postaci zrzeszeń zakupują odpowiednie rozwiązania.

Polski produkt musiałby być konkurencyjny cenowo i funkcjonalnie, a także tańszy od zachodniego systemu pod względem jego utrzymania i dalszego rozwoju. Trzeba pamiętać, że wszystkie oferowane na rynku polskim systemy ulegają stałej przebudowie, a ich funkcjonalność - rozszerzeniu. To oznacza, że kolejne kontrakty, a także opłaty serwisowe i pielęgnacyjne muszą sfinansować ich rozwój. Dla polskiego producenta oznacza to zorganizowanie stałego dopływu wiedzy technologicznej i bankowej, zbudowanie kompetencji zespołów, co nie jest dostępne praktycznie dla żadnego z polskich producentów oprogramowania.

Próby takie podejmowane na początku lat 90. miały sens, teraz wydają się spóźnione. Większość dużych banków wyposażyła się w systemy zachodnie, większość średnich też. Jednym z wyjątków jest Bank Gospodarki Żywnościowej. Polski producent systemu musi zadać sobie pytanie, jakie w takiej sytuacji ma szanse oraz jakie będą koszty sprzedaży i dostosowania systemu na rynki zachodnie lub wschodnie.

Zawsze część ciężaru pierwszego wdrożenia ponosi producent, a to oznacza duże nakłady kapitałowe, zanim inwestycja przyniesie zyski. Polski rynek bankowy nie jest prawdopodobnie w stanie utrzymać - bez zorganizowania go pod hasłami politycznymi - dużego systemu informatycznego polskiej produkcji, ponieważ jest on zbyt płytki. Dodatkowo banki postrzegają systemy zachodnie jako dopływ wiedzy i technologii.

Warto dodać jeszcze jeden aspekt polskiego rynku bankowego. Jest on w ponad 60% własnością obcego kapitału i decyzje o zakupie lub aktualizacji systemów będą zapadały poza Polską.