Systemy informatyczne dla bankowości

Trudno jest z pozycji polskiego rynku oceniać stan bankowych systemów informatycznych na świecie. Wydaje się, że istnieje nadmierna podaż miernych często systemów, przy równoczesnym braku systemów kompleksowych o nowoczesnej architekturze. Odnosi się również wrażenie, iż aktualnie na rynku istnieje niewiele systemów dostatecznie otwartych i modyfikowalnych.

Trudno jest z pozycji polskiego rynku oceniać stan bankowych systemów informatycznych na świecie. Wydaje się, że istnieje nadmierna podaż miernych często systemów, przy równoczesnym braku systemów kompleksowych o nowoczesnej architekturze. Odnosi się również wrażenie, iż aktualnie na rynku istnieje niewiele systemów dostatecznie otwartych i modyfikowalnych.

Fragmentaryczność systemu bankowego wynikać może z wielu powodów. Po pierwsze, opracowanie kompleksowego systemu bankowego wymaga ogromnych środów finansowych (setki milionów dolarów) oraz długotrwałej i przyjaznej współpracy z bankami upatrywanymi jako przyszli użytkownicy. Po drugie, złożoność funkcjonalna i algorytmiczna produktów bankowych oraz zarządzania bankiem jest trudna do pogodzenia z ograniczoną wiedzą poszczególnych osób zatrudnionych w firmie autorskiej, wymagając koordynacji i wielokrotnych rewizji już opracowanych rozwiązań. Po trzecie, trudno jest pogodzić odmienne technologie przetwarzania danych stosowane w bankowości hurtowej i detalicznej

Można zaryzykować twierdzenie, że systemy w pełni kompleksowe i pochodzące z jednej firmy autorskiej należą do rzadkości. W ciągu kilku lat pracy nad oceną wielu systemów pochodzących z różnych krajów, a nawet kontynentów (od Stanów Zjednoczonych do Australii) nie zetknąłem się z takim systemem. Czasem brakowało niewiele, a typową "dziurą " była obsługa akredytywy (którą zapełniano zwykle pakietem EXIMBILLS, pochodzącym od China Systems Corporation z Taiwanu). Drugim typowym przykładem oprogramowania uzupełniającego jest uzgadnianie rachunków NOSTRO (np. pakiet NOSTRO 400). Problem więc polega na tym, jak duże braki funkcjonalne ma system, a nie czy ich nie posiada. Często zdarza się, że specjalizowane pakiety aplikacyjne są bardziej dopracowane (w zakresie wspomagania, wielorakości raportów, tzw. kosmetyki ekranowej itp.) od systemów kompleksowych i wówczas podjęcie decyzji o włączeniu ich do systemu powinno zależeć od wbudowanych mechanizmów eksportowo-importowych (w tym reformatowania danych do potrzeb systemu głównego), zapewniających przepływ informacji dla potrzeb utrzymywania pozycji banku na bieżąco, przetwarzania zamykającego dzień itp.

Rzutuje to w sposób decydujący na możliwości adaptacyjne systemów. Im system starszy i ma więcej wdrożeń, tym trudniej poddaje się adaptacji i tym więcej wysiłku kosztuje wprowadzanie zmian. Zapewne dużo na ten temat mogłyby powiedzieć firmy BIS (autor systemu MIDAS) i Fiserv (autor systemu ICBS).

Zagadnienie modyfikowalności systemu bankowego jest rozwiązywane w rozmaity sposób. Niektóre firmy oferują bankom duże możliwości projektowo-programistyczne (np. Unisys: GWB, Navigator), co daje użytkownikom pełne możliwości panowania nad systemem, lecz wymaga szerokiego zaangażowania własnego personelu do budowy systemu za pomocą dostarczonych narzędzi.

Inni dostarczają szeroko predefiniowane produkty (np. Kirchman), w których użytkownik tylko wybiera opcje i wprowadza parametry. W tym przypadku wprowadzenie jakichkolwiek dodatkowych algorytmów wymaga zmian w kodzie żródłowym, czyli udziału autora systemu.

Wreszcie istnieją też rozwiązania pośrednie (np. w systemie Profile firmy Sanchez), w których użytkownik, poza dostępnością wielu parametrów, może sam definiować struktury danych i pisać algorytmy w ramach predefiniowanych produktów, posługując się interpretacyjnym językiem programowania MUMPS i narzędziem DATA QWIK. Zmiany te nie mogą jednakże obejmować tzw. rdzenia systemu.

Załączona obok tabela zawiera zestawienie 60 wielofunkcyjnych systemów bankowych znanych na rynku informatycznym. Nie obejmuje ona specjalizowanych pakietów aplikacyjnych ukierunkowanych na określone zagadnienia finansowe np. zarządzanie ryzykiem, obsługa akredytyw, uzgadnianie rachunków NOSTRO itp. Na przykład do pakietów zarządzania ryzykiem należą: GLS (Global Limits System) i RXM (Risk and Exposure Monitoring) firmy GEIS, Stream firmy MD, Limits firmy ACT, GLCS (Global Limits Control System) firmy Reuter.

Przy zakupie oprogramowania aplikacyjnego dla banku należy zwracać uwagę nie tylko na obsługę produktów bankowych, lecz również na software specjalistyczny zapewniający nowoczesne środowisko, np. obsługa transakcji nadchodzących z bankomatów (ATM) i punktów sprzedaży (POS) zarówno własnej, jak i obcej sieci. Realizacja tych zadań wymaga zwykle zaangażowania specjalistycznych firm (np. IFS oferująca pakiet TechNique Plus II).

Balast historii a współczesność

Wiele systemów bankowych nie ma nowoczesnego charakteru, gdyż pochodzi z połowy lat 70., a w najlepszym wypadku z połowy lat 80. Systemy te z reguły w jakimś stopniu nie przystają do naszych warunków (ale jak zwykle istnieją wyjątki), oferując z jednej strony produkty wyprzedzające nasze krajowe zapotrzebowanie, z drugiej strony nie pokrywając tego, które sami wymyśliliśmy.

Wydaje się, że okres ostatnich 2-3 lat świadczy o pozytywnych tendencjach rozwojowych w informatyce bankowej. Pojawia się coraz więcej bankowych systemów kompleksowych na otwartych platformach (unixowych) oraz pod standardowymi (relacyjnymi) systemami zarządzania bazą danych (Oracle, Sybase).

Sprzyjają temu - mimo zaostrzonej walki konkurencyjnej - wspólne przedsięwzięcia przodujących firm komputerowych mające na celu stworzenie otwartej platformy dla sieci heterogenicznych, w których współpracować będą komputery należące do różnych linii rozwojowych. Przykładem tego jest Polycenter Manager (firm Digital i IBM) łączący IBM NetView /6000 z DEC OSF/1, co ma ułatwić wdrożenie zarządzania sieciowego typu Unix TCP/IP SNMP i przyciągnięcie na OSF/1 już istniejących aplikacji zorientowanych na NetView.

Wzmacnianiu otwartości służy też działalność firm software'owych, tworzących oprogramowanie systemowe niezależne od sprzętu. Wymienić tutaj można np. firmę Forte Software Inc., tworzącą obiektowe oprogramowanie dla otwartych architektur klient/serwer.

Firmy działające na rynku systemów bankowych

Opracowanie przeglądu producentów systemów bankowych stosowanych na świecie nie stanowi łatwego zadania ze względu na bardzo ograniczone możliwości dostępu do informacji (nie licząc materiałów publikowanych w celach reklamy). Poza tym wiele systemów bankowych powstaje i działa jedynie wewnątrz banków, w związku z tym nie stanowią one przedmiotu marketingowych działań oraz publikacji.

Pionierami oprogramowania bankowego są firmy BIS, Winter Partners i Kapiti, wywodzące swoje systemy z lat 70., co ma swoje zalety (doświadczenie) i wady (niezbyt nowoczesne systemy). Uwolnienie się od balastu tradycyjnych rozwiązań zapewne nie jest łatwe, ale niektóre z tych firm pracują nad ulepszeniem systemów.

Dla przykładu, Winter Partners przeprogramowuje IBS90 i uzupełnia go poprzez system ABRAXSYS dla bankowosci detalicznej. Kapiti opracował Equation/3 oraz generator aplikacji ENIGMA (co jednakże nie uratowało tej firmy przed wykupieniem jej przez Misys Plc).

Istnieje wiele firm zajmujących się tworzeniem systemów informatycznych dla banków. Warto jednakże zauważyć, że główne ośrodki projektowania bankowych systemów informatycznych pokrywają się ze światowymi centrami finansowymi (Nowy Jork i Londyn).

Firmy produkujące oprogramowanie dla banków to często niewielkie organizacje zatrudniające zaledwie kilkanaście lub kilkadziesiąt osób, podlegające często kryzysom finansowym. Przez to zakupy systemów kompleksowych obarczone są w tym przypadku wysokim stopniem ryzyka.

Małe firmy mogą być wiarygodnymi dostawcami pakietów specjalizowanych, przeznaczonych do realizacji wybranych funkcji bankowych, np. uzgodnienia rachunków NOSTRO, uzgadnianie potwierdzeń transakcji SWIFT (tzw. confirmation matching), archiwizowanie transakcji SWIFT, obsługa akredytyw itd.

Pakiety owe powinny być wyposażone w odpowiednio elastyczne (definiowalne) łącza eksportowo-importowe danych, co w przypadku modułów operujących na komunikatach SWIFT jest zadaniem stosunkowo prostym, opartym na przeformatowaniu danych własnych na standardy SWIFT (i odwrotnie). Ryzyko związane z zakupem specjalizowanych pakietów jest stosunkowo niewielkie, gdyż nakłady finansowe są nieporównywalnie mniejsze, niż w przypadku zakupu systemów kompleksowych oraz mniejsze jest pole błędów (są mniej skomplikowane). Ponadto z małymi firmami łatwiej się "dogadywać" w zakresie zmian kastomizacyjnych (customization), gdyż mniej osób wciągniętych jest w proces decyzyjny i nie ma wąskiej specjalizacji zatrudnionych.

Zarządzanie rozwojem systemów

Panuje opinia, że na wprowadzenie dowolnej zmiany w systemie pochodzącym od dużej firmy potrzeba 2-3 lat, gdyż po pierwsze istnieje tam złożona procedura zarządzania zmianami, i po drugie, firmy takie mają dużą liczbę sprzedanych systemów których zmiany mogą też dotyczyć (w zakresie tzw. standardu).

Nie można jednakże tworzyć systemu kompleksowego wyłącznie w drodze "sklejania" pakietów pochodzących z małych firm, gdyż, mimo iż "małe jest piękne" to "duże będące ich sumą" może okazać się tworem pokracznym o niskiej wydajności (m.in.ze względu na pośrednictwo wielu mechanizmów interfejsowych) i trudnym do utrzymywania (każdy pakiet korzystać może z innej organizacji zbiorów, mieć inną organizację menu i komunikację z użytkownikami itp.). Rdzeń (jądro) systemu musi być produktem jednolitym, narzucającym nowoczesną architekturę systemu.

Podejmowanie prac nad systemami bankowymi o nowoczesnej architekturze wymaga znacznych nakładów finansowych. Ryzyko takich prac widocznie jest wysokie, skoro finansowanie ich nie znajduje dostatecznego wsparcia ze strony banków.

Główny ciężar prac rozwojowych firmy software'owe, które często nie mogą podołać finansowo ambitnym zadaniom. Wiadomo na przykład, że BIS przerwał prace nad MARSem, Credit Suisse Group - Winter Partners nad CIB, ITB nad Capital, Premier Systems nad Venus itp.

Często sami specjaliści bankowi powoływali własne firmy software'owe do opracowania systemów wg własnych koncepcji i niekiedy przeliczali się z możliwościami. Być może paradoksalnie, doświadczenia te dowodzą, że im bardziej ambitne (nowoczesne) miały być systemy, tym większe były niepowodzenia projektów.

Duże banki zachodnie często w ogóle nie korzystają z usług firm software'owych, lecz same opracowują systemy bankowe dla siebie i nie są zależne od rozwiązań istniejących na rynku. Przykładem tego może być bank Credit Agricole we Francji, który opracował system OURASI z wykorzystaniem SZBD (systemu zarządzania bazą danych) Sybase.

Rola producentów sprzętu

Producenci komputerów z reguły nie angażują się bezpośrednio w tworzenie aplikacji bankowych. Do wyjątków należy tutaj firma Unisys oferująca zarówno swój sprzęt, jak i własne systemy aplikacyjne. Również firma Digital oferuje własny system DECbank Financial Business System (DECbank-FBS) przeznaczony do obsługi oddziałów. Zapewne większość firm software'owych jest w jakiś sposób (m.in. finansowo) powiązana z firmami komputerowymi, na przykład Bluebird Software z firmą IBM dla systemów na platformy AS/400.

Niektóre firmy opracowały ogólne koncepcje tworzenia systemów dla sfery finansowej. Dla przykładu IBM lansuje "filozofię " architektury systemów finansowych FAA (Financial Application Architecture) wraz z modelem danych (FSDM - Financial Systems Data Model). Unisys propaguje natomiast koncepcję FBA (Financial Business Architecture).

Kraje Europy Środkowowschodniej stały się obecnie obiektem skoncentrowanych działań firm zachodnich w zakresie bankowości. Na uwagę w tym względzie zasługuje m.in. IBM, który w styczniu 1994 r. utworzył w Lublanie (Słowenia) centrum bankowe pod nazwą IBM EE BCC (Eastern Europe Banking Competence Centre).

Główne platformy sprzętowe systemów uwidocznionych w zestawieniu tabelarycznym to:

- Digital VAX/Alpha (DEC); oprogramowanie aplikacyjne na te komputery tworzone jest m.in. przez Winter Partners, Sanchez Associates, McDonnell Douglas

- IBM AS/400 (BIS, Fiserv, Kapiti i inne); komputery te dominują na rynku bankowym w grupie tzw. middle-range

- IBM mainframe (ManTec/MTI, EDS, Kirchman, Hogan); komputery te stosowane są głównie w bardzo dużych bankach, w których występuje wiele milionów transakcji dziennie

- PC (wiele firm).

Firmy software'owe z reguły powiązane są z pojedynczymi platformami sprzętowymi. Bardziej zaawansowane systemy bankowe odnoszą się do platform IBM albo Digital. Pewnym odstępstwem w tym względzie jest firma ITB (Information Technology for Banks) utworzona przez byłych pracowników firmy Cosmos należącej do Citibank. W ciągu 8 lat kosztem 30 mln USD firma ITB opracowała system CAPITAL przeznaczony do eksploatacji zarówno na mainframe'ach IBM, jak i komputerach firmy Digital.

Kroki podejmowane przez firmy powiązane z IBM (np. BIS, EDS) w stronę systemów otwartych, być może, wiadczyć mogą o początkach tendencji odchodzenia od dużych komputerów IBM typu mainframe oraz AS/400, aczkolwiek do oceny skali zjawiska brakuje odpowiednich danych statystycznych. Zjawisko to można określać też jako "downsizing", czyli migracja w stronę minikomputerów pracujących w środowisku sieciowym o architekturze klient/serwer.

Reakcją IBM na te pociągnięcia jest przesunięcie akcentu na korzyść systemów otwartych poprzez produkcję procesorów PowerPC, na bazie których IBM deklaruje powszechne stosowanie systemów unixowych na wszystkich swoich platformach (w tym też na AS/400).

Także Unisys w swoim systemie bankowym Urbis rezygnuje z własnego systemu operacyjnego na rzecz Unixu. Nawet ukierunkowana mocno na komputery mainframe IBM firma Kirchman oferuje system Dimension International również pod systemem Unix na komputerach NCR.

Wnioski trzeba wyciągać samemu

Analiza jakości systemów wymaga przestudiowania obszernych dokumentacji, sprawdzenia funkcjonowania systemu w tzw. miejscach referencyjnych (co najmniej dwóch), gdyż czasem to co oferent podaje jako "gotowe" znajduje się dopiero w trakcie opracowywania koncepcji. Korzystna może być również wizyta u autora systemu, gdyż wówczas można zorientować się w rzeczywistym potencjale i kwalifikacjach jego personelu.

Najwięcej korzyści daje przeprowadzona w banku tzw. postkwalifikacja, polegająca na dokładnym sprawdzeniu działania poszczególnych produktów, poprzez wprowadzanie własnych danych. Do kwestii tej warto będzie wrócić w ramach osobnego opracowania.

Jeśli dla zyskania skali porównawczej wybierze się kilka systemów do oceny, to trzeba dysponować 5-7 osobowym zespołem o odpowiednich kwalifikacjach bankowych, informatycznych i językowych, aby w rozsądnym czasie (np. poniżej 2 lat) przejść drogę od rozpoznania i sformułowania własnych potrzeb do zawarcia kontraktu.

Warto też zaznaczyć, że samo opracowanie szczegółowych wymagań w zakresie produktów bankowych (szczególnie w zakresie skarbowości i operacji zagranicznych) oraz architektury systemu, może okazać się zadaniem wymagającym zatrudnienia konsultantów zagranicznych, którym trzeba dużo płacić i których trzeba umieć wykorzystać!. Wykorzystując tych konsultantów powinno się równocześnie doceniać wiedzę i kwalifikacje własnych pracowników.

Krajowe systemy bankowe

Systemy krajowe nie stanowią przedmiotu niniejszej publikacji, jednakże konieczne jest chociaż skomentowanie niektórych ich cech, aby stworzyć pewne tło dla ewentualnej analizy porównawczej.

Przede wszystkim nie sposób wstrzymać się od twierdzenia, że ukierunkowane są one głównie na tradycyjną operacyjną działalność bankową, polegającą głównie na obsłudze klientów indywidualnych. Ponadto są zwykle zbudowane w przestarzałej technologii zorientowanej na konta księgowe, nie zaś na klientów. Nie są wielowalutowe, nie mają modułów obsługi operacji zagranicznych, wielu instrumentów finansowych, papierów wartościowych, nie dokonują prognozowania sytuacji finansowej banku, nie stosują zaawansowanych metod liczenia ryzyka w stosunku do klientów, walut i krajów itp.

Istnieje kilka przyczyn tego stanu rzeczy. Jedną z nich jest brak wiedzy bankowej, a często i praktyki bankowej w powyżej wzmiankowanym zakresie oraz brak dostatecznego doświadczenia w projektowaniu systemów bankowych.

Zbudowanie dobrego systemu bankowego wymaga wielu lat. Jedną z ważnych przesłanek jest (poza zaangażowaniem poważnych środków finansowych) długotrwała integracja zespołu projektowego, umożliwiająca doprowadzenie założeń do realizacji przy ścisłej i życzliwej współpracy jakiegoś banku (przewidzianego do testowania prototypu). Przekształcenie prototypu (nawet najlepszego) w system eksploatacyjny zajmie następnych kilka lat. W sumie pełny cykl budowy kompleksowego systemu bankowego często przekracza 10 lat i stanowi dorobek całego życia zawodowego jego twórców.

Zapewnienie bezbłędnego działania wielu (np. tysiąca) programów w krytycznych warunkach przetwarzania (czas rzeczywisty, tysiące terminali rozproszonych w sieci, ryzyko finansowe prawie każdej transakcji) stanowi wyzwanie nieporównywalne do tradycyjnych aplikacji typu systemy kadrowo-płacowe oraz gospodarka materiałowa.

Na razie wypada nam uczyć się od bardziej doświadczonych, przejmować najlepsze podejścia metodologiczne i najlepsze systemy, aby startując bez obciążeń "historycznych", czyli bez powtarzania tych samych błędów uzyskać odpowiednio lepszy efekt.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200