Bankowość jest obecnie jedną z prężniejszych dziedzin aktywności gospodarczej w naszym kraju. Niektórzy szacują, iż roczne zapotrzebowanie na narzędzia informatyczne wśród ponad 3 tys. oddziałów banków, w tym ok. 1600 banków spółdzielczych i pozostałych 100 banków większych, wynosi ok. 100 mln USD rocznie. Nic więc dziwnego, że do utwardzanych żaroodporną stalą złotych wrót tych instytucji puka bardzo wiele firm, które oferują towar o zróżnicowanej jakości, cenach i zastosowaniach. Robią to również zagraniczni i rodzimi twórcy wszelkiego rodzaju

oprogramowania.

Jak zorientować się wśród tylu ofert oprogramowania bankowego? Które produkty przedstawiają jakąś wartość, a z których należy zrezygnować od razu? Wbrew pozorom, wielogodzinne testowanie programów może nie przynieść jednoznacznej odpowiedzi na to pytanie. Wydaje się, iż o wiele istotniejszą rzeczą jest to, żeby

• oprogramowanie, które kupujemy, było przetestowane w praktyce przez wielu użytkowników o potrzebach podobnych do naszych

• firma sprzedająca produkt miała siedzibę blisko oddziałów banku

• produkt był nadal rozwijany pod kątem zmieniających się potrzeb.

Lista oprogramowania oferowanego polskim bankom liczy ok. 50 pozycji. Jest to zarówno oprogramowanie rodzime, jak i zachodnie. Nie stawiając przeszkód firmom zachodnim, włączyliśmy do zestawienia tylko te ich produkty, którymi opiekuje się w kraju co najmniej jedno biuro przedstawicielskie. Innym kryterium było, czy dana firma odważyła się przedstawić swój produkt na jakiejkolwiek otwartej prezentacji, towarzyszącej rozlicznym imprezom wystawienniczym organizowanym w Polsce w ostatnich 2 latach. Poniechaliśmy na razie prezentacji produktów polskich, które są dopiero tworzone. Celem naszym jest raczej opis oferty systemów bankowych rzeczywiście gotowych do wdrożenia.

Rodowody banków i ich systemów

W zaprezentowanym przeglądzie oprogramowania oferowanego dla banków przeważają nowe produkty, które etap pierwszego wdrożenia przechodziły nie wcześniej niż 3-4 lata temu. Jest to niewątpliwie wyznacznikiem nowej epoki, w którą wkroczyliśmy w okresie rewolucyjnych przemian roku 1989, kiedy to na podstawie znowelizowanego prawa bankowego (ustawa z dnia 31 stycznia 1989 r., Dz.U. nr 4, poz. 21) i wcześniejszego rozporządzenia RM (11 kwietnia 1988 r.) wybrane oddziały Narodowego Banku Polskiego zostały przekształcone w 9 następujących banków: Bank Gdański Bank Przemysłowo-Handlowy w Krakowie, Bank Depozytowo-Kredytowy w Lublinie, Powszechny Bank Gospodarczy w Łodzi, Wielkopolski Bank Kredytowy w Poznaniu, Pomorski Bank Kredytowy w Szczecinie, Państwowy Bank Kredytowy i Bank Zachodni we Wrocławiu. Zliberalizowane prawo bankowe pozwoliło również

na łatwiejsze tworzenie całkowicie nowych banków, które komputeryzowały się już zupełnie bez obciążeń przeszłości. Może między innymi dlatego obecna sytuacja technologiczna Narodowego Banku Polskiego jest znacznie gorsza od stanu informatyki w bankach o znacznie uboższych tradycjach.

Co prawda spotyka się twierdzenia, iż wiele z "nowych" systemów bankowych nigdy by nie powstało, gdyby ich twórcy nie wynieśli wysokich kwalifikacji i bogatych doświadczeń z firm, gdzie pracowali poprzednio. W sumie świadczy to jednak na korzyść firm, które w ciągu kilku miesięcy od daty powstania umiały stworzyć, zaprezentować, sprzedać i wdrożyć w banku oprogramowanie. Fachowość twórców może rokować szanse na to, że nie wszystkie typowe wpadki świeżych systemów bankowych będą ćwiczone na młodych organizmach dopiero co uformowanych instytucji bankowych.

Produkty są stosunkowo nowe, co ma tę zaletę, że nie posiadają zbyt wielu naleciałości z poprzednich epok, kiedy z założenia polityka banków wyglądała zaupełnie inaczej. Z drugiej strony produkty te nie miały szans przejść zbyt wielu testów, przez co zapewne zawierają mimo wszystko sporą porcję nie wykrytych błędów.

Oferta funkcjonalna systemów

Prezentowane systemy oferują mniej lub bardziej kompleksową obsługę oddziału banku, z niewielkim i na ogół niezbyt dogłębnie wypróbowanym modułem łączności międzyoddziałowej. Na usprawiedliwienie tego ostatniego mankamentu można by dorzucić, iż trudno jest wypróbować oprogramowanie łączności cyfrowej w sytuacji, gdy w sieciach publicznych doświadczamy zupełnie podstawowych trudności z łącznością typu analogowego.

We wszystkich systemach możemy prowadzić obsługę w okienku bankowym (przy ladzie), podstawowe typy rachunków bankowych i obsługę kredytów (już tylko prawie wszędzie). Dalej następują kolejne funkcje wykorzystywane w organizacji krajowych banków, a więc stanowisko dysponenta, księgowość banku, bilanse końca dnia, sprawozdawczość, generowanie dokumentów itd.

Dodatkowo można znaleźć funkcje dla wybrańców, tj. administratorów systemu (informatyków), wysoko kwalifikowanych księgowych, bądź wyznaczonych osób bezpośrednio wykonujących polecenia kierownictwa banku (np. asystentów dyrektora).

Zbiór główny

Nazwa ta przysługuje podstawowej bazie danych aktualnego stanu rozliczeń banku uzupełnionej o dane pomocnicze, takie jak: daty zawarcia umów, terminarz realizacji ich kolejnych etapów itp. Zbiór główny powinien posiadać stosowną liczbę kopii zapasowych. Przeważnie na koniec dnia wykonuje się jeden egzemplarz kopii zapasowej (backup) na taśmie magnetycznej, ale wskazane jest w rzadszych okresach wykonywanie drugich kopii dodatkowych. Wtedy, w razie awarii dysków, przy nieprzewidzianej utracie pierwszej kopii taśmy, posiadanie kopii sprzed kilku dni może nam ułatwić uzupełnienie danych. Częstotliwość wykonywania drugich kopii powinna być oczywiście podyktowana takimi czynnikami, jak dzienna liczba wykonywanych w banku operacji i awaryjność

sprzętu.

On-line czy off-line

Wszystkie operacje prowadzone na terminalach komputerowych mogą być notowane albo w zbiorach podręcznych, albo od razu wchodzić w zawartość zbioru głównego. Ta pierwsza metoda (off-line) jest zazwyczaj nieco tańsza i prostsza w realizacji, operację aktualizacji zbioru głównego przeprowadza się w tym przypadku po zamknięciu oddziału. Praca off-line sprzyja przechowywaniu stanu konta z poprzedniego dnia. Wadą tej metody jest niemożność monitorowania wybranych wskaźników pracy banku bez jednodniowego opóźnienia.

Od metody off-line przechodzi się wszędzie, gdzie to jest możliwe, do metody czasu rzeczywistego (on-line). W tej drugiej metodzie stosuje się nieco inne, programistyczne, sposoby śledzenia historii stanów konta po kolejnych operacjach. Tryb on-line pozwala na monitorowanie wskaźników stanu banku na bieżąco.

Architektura klient/serwer

Słowo klient w tym artykule ma aż 3 znaczenia. Pierwsze jest zrozumiałe - klient banku, czyli nabywca jego produktu. Drugie będzie się pojawiało tylko sporadycznie: bank jest bowiem niewątpliwie klientem firm komputerowych, u których kupuje czy to sprzęt, czy oprogramowanie, lub wreszcie instalację pod klucz.

Trzecie znaczenie słowa klient odnosi się do architektury systemu komputerowego. Oznacza to, że część zadań realizowanych na komputerze (na ogół PC) pracownika bankowego nie musi być realizowana procesorami komputera centralnego (serwera). Architektura taka pozwala na zmniejszenie obciążenia zarówno procesorów, jak i pamięci masowej serwera, a jednocześnie lepsze zabezpieczenie lokalnych danych przed niepowołanym dostępem.

W zestawieniu 10 systemów bankowych (por. tabela) łatwo zauważyć, że większość z nich jest zrealizowana w architekturze klient/serwer w sieci Novell NetWare.

Mimo że architektura k/s zmniejsza czas pracy komputera centralnego i wydawałoby się, iż w związku z tym dopuszcza konfigurację z większą liczbą terminali, zaprezentowany przegląd instalacji bankowych niezupełnie to potwierdza. Ankietowani producenci systemów bankowych pracujących w środowisku NetWare/DOS, przeciętnie legitymowali się maksymalną instalacją złożoną z 40 terminali. Absolutnym rekordzistą w tej dziedzinie jest bydgoska SABA ex aequo z krakowskim SoftNetem, którzy mogą się poszczycić aż 50-terminalowymi instalacjami.

Zdecydowanie jednak przelicytowują ich producenci systemów unixowych z centralnym komputerem i nieinteligentnymi terminalami. Warszawski Softbank osiągnął tu maksymalną liczbę 60 końcówek, a NCR/ICS aż 80. Osobna uwaga należy się systemowi CSBI Bankier pracującym w architekturze k/s. Pod Unixem w warszawskiej centrali Kredyt Banku zdołano zainstalować ów system "ciągnący" aż 300 terminali. Przy tak wielkiej liczbie prawdopodobnie rezygnacja z architektury k/s byłaby już po prostu niemożliwa.

Tak więc w naszym kraju architektura k/s stosowana jest w małych instalacjach bankowych oraz bardzo dużych. Natomiast średnie konfiguracje rzędu 100 terminali najczęściej korzystają z rozwiązań unixowych. Oto wnioski praktyczne, niewątpliwie zasługujące na uwagę nie tylko zagorzałych zwolenników sporów "Unix kontra Novell", ale także obserwatorów wdrożeń scentralizowanych i rozproszonych pod systemem Unix.

Łącza z innymi bazami danych

Jako się rzekło, prezentowany przegląd systemów bankowych obejmuje produkty powstałe stosunkowo niedawno. Tymczasem historia komputeryzacji banków polskich liczy już przecież ponad 20 lat. W przeszłości banki polskie komputeryzowały się w dwóch zasadniczych etapach. Pierwszy z nich miał miejsce na przełomie lat 60. i 70., a dotyczył NBP i pozostałych dużych banków. Drugi etap jest związany z wczesną fazą rewolucji pecetowej lat 80., kiedy to genialny szwagier wójta w ciągu dwóch nocy pisał system zaprzyjaźnionemu prezesowi miejscowego banku spółdzielczego. Pierwszy etap rozwoju zaowocował powstaniem standardu zapisu danych systemu NBP SOB (System Operacji Bankowych), pracującego na bardzo już dziś zabytkowych komputerach mainframe NCR czy RIAD (RWPG-owskich klonach IBM). Z drugiego etapu pochodzi praktyka stosowania takich formatów baz danych jak miniSOB czy Clipper.

Formaty, a konwersja danych

Twórcy nowych systemów muszą się liczyć z tym, że przechodzenie od starszego oprogramowania jest procesem ciągłym. Bank nie może na kilka tygodni zamknąć drzwi przed klientami z powodu zmiany systemu. Dlatego też opracowano metody jednoczesnej pracy na starym i nowym formacie danych. W ten sposób stare dane poddawane są powolnej transformacji, aż do całkowitego "przetłumaczenia" ich na nowy format. Takie podejście w niektórych wdrożeniach stosują twórcy systemu NCR/ICS TABO. Nieco inaczej postępuje firma CSBI. Jej dyrektor Sławomir Chłoń twierdzi, że konwersja danych w banku powinna się dokonać w ciągu 1-2 dni wolnych od pracy. Ten typ operacji jest bardzo drogi, ale daje komfort, że w przysłowiowy "poniedziałek rano" wszyscy pracownicy banku pracują w nowym zunifikowanym systemie. Warunkiem powodzenia takiej konwersji, twierdzi dyr. Chłoń, jest ścisła współpraca pracowników banku z pracownikami wdrażającymi system. Po pierwsze bowiem szybką konwersję należy poprzedzić cyklem szkoleń, a poza tym pewien niewielki procent danych może wymagać dodatkowo bardziej żmudnych, niestandardowych metod przenoszenia.

Zabezpieczenia

Można wyróżnić dwa rodzaje zabezpieczeń zrealizowanych w systemach bankowych. Pierwsze z nich koncepcyjnie niewiele odbiegają od tego, co oferuje dowolny wielodostępny system operacyjny. Są to więc hierarchie haseł dostępu, zabezpieczenia używania poszczególnych funkcji, operacji, a nawet ograniczenia wglądu do pojedynczych kont klienta. Dodatkowo można zainstalować oprogramowanie, notujące każdą operację wykonaną na danym terminalu. Są to jednak wszystko zabezpieczenia od wewnątrz, które służą unikaniu zarówno dywersji aranżowanej przez pracowników banku, jak i zwykłego ich roztargnienia.

Istnieją jednak co najmniej równie poważne zagrożenia zewnętrzne. Jeszcze do niedawna w modelu pracy polskiego banku pojęcie ryzyka bankowego praktycznie nie istniało. Gdy jakieś przedsiębiorstwo nie spłacało kredytu, karna nacjonalizacja krnąbrnej, ale już dawno upaństwowionej firmy nie miała wielkiego sensu. Mimo wielu zmian do dzisiaj trwamy w sytuacji, gdy klient z przyzwyczajenia przychodzi do banku po kredyt od razu z zakładając jego niespłacenie. Takich problemów na masową skalę banki zachodnie nie notują. Zarzuca się bankom polskim brak mobilności w pewnych dziedzinach. Tymczasem to ich klienci nie przestrzegają podstawowych zasad np. ubiegania się o kredyty. Zbyt często nie potrafią sporządzić dobrego business planu, nie mówiąc już o bardziej wyrafinowanych wymaganiach formalnych. Narzeka się np., że nie są wykorzystane zagraniczne linie kredytowe. Ale mało kto dodaje, że dzieje się tak, ponieważ tam stawiane są konkretne wymagania, które trzeba spełnić.

Ryzyko bankowe, ponoszone wskutek niewłaściwego doboru klienta można łatwiej ocenić poprzez odpowiednie oprogramowanie systemu komputerowego. Idea tych zabezpieczeń jest prosta. Należy komputer nauczyć myśleć, a nawet wyposażyć go w coś w rodzaju "szóstego zmysłu". Nie każda bowiem operacja, wykonywalna z punktu widzenia arytmetyki, czy nawet przepisów, powinna być dopuszczana.

Takie żądanie nie jest niestety łatwe do zrealizowania. Komputer bowiem powinien być wyposażony w osobny moduł, działający na zasadzie systemu ekspertowego. Na razie realizacje zabezpieczeń logicznych są, z uwagi na wysokie koszty, znacznie uboższe. Jedni twórcy oprogramowania ograniczają się tu do rejestracji "sum wysokich i podejrzanych", czy "kontroli spójności danych", inni zaś stosują nieco bardziej wyrafinowane metody analizy rozproszonych dokumentów. Wydaje się, że najdalej w zabezpieczeniach merytorycznych poszła w tej chwili firma Softbank. Jej prezes Aleksander Lesz odmówił jednak podawania zbyt szczegółowych danych o merytorycznych zabezpieczeniach systemu ZORBA. I słusznie.

Dokumentacja i podpowiedzi

Warto przed zakupem systemu zwrócić uwagę na te dwie cechy oprogramowania bankowego. Co do możliwości wywoływania podpowiedzi na ekran, nie każdy twórca oprogramowania jest przekonany o ich konieczności. Jedni ograniczają się do ekranów administratora systemu (TABO), inni wyposażają w "help" każdą operację operatora (Multibank), wreszcie niektórzy realizują system całkowicie bez podpowiedzi. Stosowana jest też wersja kompromisowa bez podpowiedzi: rozwijalne (pull-down) menu, którą oferuje np. system SoftNet.

Dokumentacja systemów bankowych wykazuje w polskich warunkach wiele cech wspólnych. Opracowuje się więc przede wszystkim jej szczebel podstawowy, przeznaczony dla operatora używającego określonego zestawu funkcji. Oferuje się też na ogół wersję zaawansowaną dokumentacji, przeznaczoną dla administratora systemu. Czasami te dwie części dokumentacji uzupełniane są trzecią, która stanowi coś w rodzaju opisu języka programisty, co pozwala użytkownikowi dobudować pewne własne procedury systemu (defBANK).

System jak system, ale te metody... serwisu

Szaleństwem jest kupować narzędzie tak skomplikowane jak system bankowy bez gwarancji. Większość firm udziela w cenie systemu gwarancji rocznej oraz składa obietnicę upgrade'ów w tym okresie. Serwis dla oprogramowania jest organizowany bardzo różnie. Ponieważ zazwyczaj serwis udzielany jest na całość wdrożenia, a więc sprzęt z oprogramowaniem, bywają firmy, które gwarancję dla oprogramowania wiążą z usługą kompleksowego wsparcia technicznego.

System bankowy nie toleruje przerw w pracy dłuższych niż kilka godzin. Dlatego, w porównaniu z supportem dla innych zastosowań komputerów, wsparcie techniczne dla banków jest stosunkowo drogie (ok. 15% całkowitej ceny systemu rocznie). Ale i wachlarz usług jest tu szerszy niż gdzie indziej. Zaczyna się od stałych dyżurów telefonicznych (hot-line), prowadzonych przez niektórych producentów niemal 24 godz. na dobę, a kończy na umowach o zapewnieniu likwidacji awarii nawet i w 4 godz po jej wystąpieniu. Stosunkowo nową techniką pomocy, bardzo ułatwiającą życie serwisantom jest tzw. zdalny login. Oznacza on modemowe podłączenie do systemu klienta z siedziby firmy. Czasami już taka ingerencja wystarcza do naprawienia powstałych uszkodzeń.

Warto dodać, że ceny wsparcia technicznego dla wdrożonego systemu są w Polsce ok. 10-krotnie niższe od cen dla analogicznych wdrożeń na Zachodzie.

Sieci globalne

Omawiane systemy bankowe starają się nadążać za nowinkami technicznymi w dziedzinie łączności. W rubryce dotyczącej interfejsów z sieciami globalnymi, w drodze wyjątku pozwoliliśmy firmom popuścić wodze fantazji i zadeklarować, jakie to łącza oferują ich systemy. Rzadko które z wymienionych możliwości są funkcjami wdrożonymi na poziomie komunikacji międzybankowej. Łącza X.25, radiolinie, czy interfejs w formacie SWIFT co prawda dość łatwo zrealizować, natomiast większym problemem w praktyce bankowej jest zdolność bezpiecznego nadania i odbioru tego rodzaju danych.

Zapowiedzi

Zmorą każdego, kto próbuje zorientować się w ofercie systemów bankowych w naszym kraju, jest stałe oddzielanie tego co już działa, od tego co znajduje się jeszcze w sferze obietnic. Na pytanie, co oferuje dany producent oprogramowania najczęściej można usłyszeć: "mój system może wszystko", albo "jesteśmy w stanie bez problemów dokonać upgrade'u z dowolnego formatu danych, ale najpierw podpiszcie z nami umowę i wpłaćcie zaliczkę" itd., itp.

Tym niemniej, wiele firm-producentów obserwuje uważnie zarówno trendy światowe, jak i wymagania klientów. Dlatego oferowane systemy bankowe powoli dojrzewają. Wzbogacają się o rozliczenia wielowalutowe, migrują od jednych systemów operacyjnych do drugich, potrafią obsłużyć coraz bardziej wyrafinowane wymagania bankowe: łączność z giełdą, operacje wekslami. Bankowcy zaczynają ostatnio domagać się narzędzi do prezentacji graficznej, a także doceniać funkcje do prognoz i statystyk. Walka pomiędzy producentami ciągle trwa. Miejmy nadzieję, że wygrają najlepsi.