Dr Zygmunt Ryznar 2005 r. Wybór systemu informatycznego Wybór systemu bankowego naley do zadania wyjtkowo odpowiedzialnego, co wynika zarówno z natury samej bankowoci jak i zonoci rozwiza informatycznych oraz wysokoci nakadów finansowych. Bankowo posiada swoj specyfik a jedn z jej cech jest to, e przetwarzanie informacji ma miejsce nie tylko wtedy, kiedy drzwi banku s otwarte dla klientów lub realizowana jest transakcja internetowa. Pienidz w banku zawsze pracuje : trzeba nalicza odsetki od sald na rachunkach, kapitalizowa lokaty w okrelonych umowami terminach, realizowa w okrelonych dniach kontrakty terminowe i inne transakcje z tzw. dat efektywn, oblicza opaty od transakcji oraz od utrzymywania rachunków, kontrolowa terminy spat kredytów, realizowa zlecenia stae z kont osobistych, systematycznie (np. codziennie) mierzy ryzyko bankowe (klientów, walut, krajów...) oraz pynno finansow itp. W banku prowadzi si zwykle kilkaset rodzajów produktów bankowych, wystpuje ponad tysic typów transakcji i kady z tych elementów potrzebuje odrbnej - w sensie algorytmicznym - obsugi. Duy bank utrzymuje kontakty z milionami klientów o rónorodnym profilu i kady z nich wymaga staego serwisu informacyjnego (w postaci chociaby wycigów bankowych). Podstawowym warunkiem sprawnego funkcjonowania systemu jest wic odporno oprogramowania na tzw. zawieszenia, niezawodno techniczna zarówno sprztu komputerowego jak i linii telekomunikacyjnych. Cia obsuga operacji jest konieczna m.i. w przypadku telebankingu, w tym dla bankomatów pracujcych on-line, oraz oddziaów wirtualnych (internetowych) funkcjonujcych non-stop. W tym ostatnim przypadku konieczne jest przyjmowanie transakcji równie podczas zamykania dnia, a wic w godzinach nocnych. Wymaganie stawiane systemom nosz wic tzw. krytyczny charakter, porównywalny pod wzgldem niezawodnoci z oprogramowaniem do sterowania procesami technologicznymi. Bank bankowi nierówny. System informatyczny banku komercyjnego jest tworem nieporównywalnie bardziej zonym ni maego detalicznego banku depozytowego kredytowego. O zonoci biznesu i systemu bankowego wiadcz najlepiej ponisze dane: Duy wolumen baz operacyjnych i hurtowni danych, zwykle sigajcy kilkuset gigabajtow (GB) a czasem mierzony terabajtami (TB) czy nawet betabajtami (BB). Wikszo transakcji realizowanych jest w czasie rzeczywistym. Intensywno napywu transakcji (szczególnie w bankowoci detalicznej), wynoszca np. kilkaset tysicy transakcji dziennie (w skali banku). Samodzielno transakcji i kontraktów. S one utrzymywane tak jak rekordy gówne baz danych, np. transakcje dilerskie, kolejne lokaty itp. rozliczane s w czasie, przechowywane w bazach operacyjnych a do momentu ustania ich aktywnoci. Wystpowanie produktów i transakcji z datami efektywnymi (do przodu i do tyu), zwanymi datami zapadalnoci, wymagalnoci i dat wartociowania ( value date ). Wystpowanie operacji inicjowanych z okrelon czstotliwoci (np. pierwszego dnia miesica, na koniec kwartau, na koniec roku itp.) lub te realizowanych wg harmonogramu uzgodnionego z klientem (np. przy spacie niektórych kredytów). Rónorodno typów transakcji: (dla banku uniwersalnego ponad 1000 ). Midzynarodowy globalny charakter transakcji, a wic kontrahenci (banki i klienci banków) pochodzi mog z dowolnego kraju, stosowane s róznorodne waluty, wahania ich kursów na rynku midzynarodowym oraz sytuacja klientów wpywaj na pozycj finansow banku Niejednorodny charakter stosowanego w bankach systemu informatycznego: czsto jest to zestaw wielu specjalizowanych pakietów pochodzcych od rónych wytwórców. Stwarza to powane problemy integracyjne i utrudnia uzyskiwanie informacji globalnych w skali banku. Dua zono produktów bankowych i instrumentów finansowych, wynikajca ze skomplikowanych algorytmów (liczenia odsetek, rat kredytowych, odsetek karnych itp.), wystpowania wielu stowarzyszonych transakcji (awiza, potwierdzenia, opaty, patnoci, uzgodnienia rachunków nostro itp.), porednictwa banków zagranicznych itp. Relacje algorytmiczne pomidzy obiektami (klientami; rachunkami, itp.) Wysokie obcienie zarówno obsug transakcji w czasie rzeczywistym jak i wsadowym przetwarzaniem (podczas tzw. zamykania dnia oraz dla potrzeb zarzdzania finansami banku). Narzuca to konieczno podziau zasobów infiormacyjnych na bazy operacyjne i hurtownie danych.
Realizacja transakcji wasnych oraz w imieniu klientów (np. w zakresie papierów wartociowych) Wysoki stopie ryzyka finansowego wymaga jego pomiaru (w tym prognozowania) na populacji wielu obiektów zarówno za pomoc metod statystycznych jak i nieliniowych (opartych np. na modelach neuronowych). Do obsugi dat wstecznych oraz do pomiaru ryzyka niezbdne jest utrzymywanie plików historycznych (np. historii kursów wymiany, stóp procentowych ) Wymaganie bezbdnoci dziaania oprogramowania aplikacyjnego i zabezpieczenia przed nieuprawnionym dostpem (gdy tam gdzie s pienidze wszystko jest moliwe). Warto wspomnie te o tak oczywistych wymaganiach jak przyjazny charakter systemu (atwo obsugi przy równoczesnym spenieniu wymaga bezpieczestwa, podpowiedzi przy wprowadzaniu danych do poszczególnych pól, zrozumiae komunikaty ostrze i bdów itp.), poprawno algorytmów aplikacyjnych oraz wysoki stopie bezbdnoci kodu programowego. Wybór systemu odbywa si w oparciu o szczegóowe wymagania, których zwykle jest wiele, wszystkim naley sformuowa nadrzdne kryteria wyboru systemu bankowego przede Stopie komplikacji w konkretnych sytuacjach zaley od pozycji wyjciowej banku, któr w najlepszym kracowym przypadku - dla nowego banku - moe by komputeryzacja od zera, a dla banku istniejcego równoznaczna z zarzuceniem dotychczasowego dorobku informatycznego, lub tylko ulepszenia istniejcych rozwiza. Róne mog by te kryteria oceny przydatnoci systemu dla okrelonego banku, gdy zale one od wielkoci, specjalizacji i moliwoci finansowych. Podstawowe nadrzdne - wymagania pozostaj jednak niezmienne: Funkcjonalno, modyfikowalno, nowoczesno i zdolno do integracji z innymi aplikacjami i technologiami czyli zdolno obsugi tych produktów, które potrzebuje bank "tu, teraz i potem", cena kompletna (oprogramowanie, sprzt, kastomizacja, integracja, wdroenie, wsparcie techniczne) jej wysoko powinna znajdowa si w relacji do jakoci i zakresu systemu, moliwoci patniczych banku i wymaganego okresu zwrotu nakadów. Ceny wszystkich ofert powinny by doprowadzone do warunków porównywalnych, czyli dla tego samego zakresu usug i sprztu. Przepustowo czyli zdolno obsugi takiej iloci transakcji, klientów i rachunków, jak bank planuje osign w najbliszych latach Referencje oferowanego systemu czyli potwierdzenie oferty poprzez wdroenia w innych bankach (chodzi o referencje dotyczce przede wszystkim oferowanej wersji systemu a nie spisu wszystkich kontaktów handlowych) Pozycja dostawcy: kondycja finansowa, brak zagro typu wrogie przejcie (oznaczajce najczciej zlikwidowanie produktu przez konkurenta przejmujcego), wsparcie dla odbiorców podczas wdraania i eksploatacji itp. Ze wzgldów objtociowych nie bdziemy szczegóowo rozwija tutaj wszystkich tych wymaga, lecz skoncentrujemy si na niektórych. Kryterium zakresu funkcjonalnego wymaga nie doranego lecz strategicznego spojrzenia. Ogólnie rzecz biorc, lepiej jest kupowa system kompleksowy, gdy unika si wtedy nakadów na integracj aplikacji pochodzcych od rónych wytwórców. Kompleksowo odnosi si do zakresu funkcjonalnego, rodzajów linii obsugi klienta (kanaów dystrybucji), zasigu organizacyjnego (centrala i oddziay) itp. Kompleksowo od strony funkcjonalnej jest szczególnie istotna w przypadku banku uniwersalnego, który wyrónia si tym, i prowadzi usugi zarówno w zakresie bankowoci komercyjnej/korporacyjnej (zwanej te "hurtow" od teminu angielskiego "wholesale banking") i "detalicznej " (od "retail banking"). System bankowy powinien by nie tylko kompleksowy, lecz równie spójny (ongi mówio si "zintegrowany"). Spójno dotyczy szczególnie jednolitego ujcia informacji o klientach, limitach, ksigowaniach i centrach kosztów. Integracja bankowoci hurtowej i detalicznej nastpowa powinna poprzez stosowanie wspólnych baz danych (klientów, banków, rachunków Nostro, walut, kursów wymiany, stóp procentowych, itp) dziki
czemu wyeliminowa mona operacje przeformatowa oraz importu/eksportu danych pomidzy aplikacjami. Funkcjonalne wymagania w stosunku do systemu nie powinny by ograniczane do dziaalnoci operacyjnej lecz maj obejmowa te zarzdzanie finansami caego banku (w tym zarzdzanie ryzykiem), w szczególnoci wtedy gdy bank dziaa (lub zamierza dzia ) na rynku kapitaowym i inwestowa w papiery wartociowe albo stosowa instrumenty deratywowe. Uzyskanie informacji o pozycjach klientów, walut oraz wraliwoci rozwarcia (pomidzy przypywem i odpywem gotówki ) na zmiany stóp procentowych, zyskownoci stosowanych produktów w projekcji na przysz itp. stwarza podstawy do wypracowania strategii finansowej banku. System powinien by modyfikowalny Znaczn elastyczno systemu bankowego mona osign poprzez metody parametryzacji nie wymagajce zmian w oprogramowaniu ródowym i oparte na zawartoci modyfikowalnych tablic. Zazwyczaj one bezpieczne (zwykle przetestowane wielokrotnie) i szybkie (wymagaj godzin - czasem tylko minut - a nie dni W systemie bankowym zada do modyfikowania jest wiele, nie we wszystkich przypadkach efekt osigany jest tylko poprzez parametryzacj. Wymiemy najistotniejsze: 1. definiowanie produktów i transakcji, 2. definiowanie planu kont i ksigowa, 3. generowanie menu dla klas uytkowników, 4. mono definiowania przez bank wasnych pól wraz z algorytmami ich obsugi, 5. generowanie ekranów, zawierajcych dowolne dane i definiowalne nagówki danych, 6. generowanie raportów za pomoc pisarzy raportów dostosowanych do poziomu róznych ytkowników : uytkownika kocowego, administratora systemu, programisty (do definiowania onych zapyta i algorytmów obliczeniowych), 7. atwe uzyskiwanie wielowymiarowych raportów i prezentacji graficznych danych na podstawie wzorców raportów i wspomagania w zakresie doboru pól danych 8. narzdzia konfigurowania i ustawiania (tuning) pod ktem optymalnej wydajnoci w warunkach danego systemu operacyjnego, systemu zarzdzania baz danych, i systemu zarzdzania sieci komputerow 9. definiowanie za pomoc parametrów zakresu (typów transakcji) pozycji klienta, waluty, banku. 10. wbudowanie mechanizmów cznoci z innymi aplikacjami (zwykle poprzez tzw.middleware). System powinien by wydajny: obsuga kilkadziesiciu transakcji bankowych na sekund kilka tysicy równoczesnych pocze internetowych w systemie elektronicznej bankowoci oraz ciy charakter pracy (24 godziny przez 7 dni w tygodniu) najwyej kilkugodzinny (do 6 godzin) czas zamykania dnia kilkusekundowy czas odpowiedzi przy obsudze operacyjnej klientów zdolno aktualizacji sald rachunków w czasie rzeczywistym (czyli natychmiast po zaakceptowaniu transakcji) zdolno szybkiego wyszukania danych historycznych o dszym horyzoncie czasowym (np. historii rachunku, zmian stóp oprocentowania, kursów wymiany walut itp.) Wydolno systemu bankowego jest wypadkow wydajnoci uytego zestawu komputerów, przepustowoci sieci teletransmisyjnej oraz sprawnoci systemów aplikacyjnych. System powinien by wyposaony w nowoczesn technologi: Poza transakcyjnym przetwarzaniem powinien zawiera (lub umoliwia integracj) takich technologii jak hurtownie danych, multichanneling (w tym internetowy kana obsugi, call center ), zasilanie zapasowych centrów obliczeniowych, automatyczna kontrola spójnoci baz danych i szybkie powstawanie (recovery) po awariach itp.. Ocena wielomoduowych systemów bankowych jest zajciem skomplikowanym i obarczonym zawsze pewnym stopniem ryzyka. Jak nadmienilimy, wynika to ze zonoci zarówno dziaalnoci bankowej jak i komplikacji rozwiza informatycznych (zwykle system zawiera kilka tysicy programów). Na rynkach (krajowym i zagranicznych) istnieje wiele systemów bankowych zwanych czsto kompleksowymi, co jest przewanie tylko czciow
prawd, oraz mnóstwo pakietów specjalizowanych. Orientacja na rynku systemów bankowych jest utrudniona, gdy nie jest atwo (co ley w interesie stron oferujcych te systemy) uzyska informacje o ich architekturze i obsugiwanych produktach bankowych, nie mówic ju o cenie (i ocenie), stanowicej zwykle tajemnic handlow. Wypracowanie obiektywnych informacji o systemach jest niemoliwe na podstawie dokumentacji marketingowej i spotka z dostawcami lub autorami. Naley zapozna si z ich dokumentacj (która nie zawsze jest, a jak jest to czasem jest nieaktualna), dokona weryfikacji dziaania systemu na tzw. preinstalacji demo u siebie oraz sprawdzi referencje u co najmniej dwóch porównywalnych z naszym - banków uytkujcych system. Sprawdzenie funkcjonowania systemu w miejscach referencyjnych jest konieczne, gdy czasem to co oferent podaje jako gotowe znajduje si dopiero w fazie obietnic (typowa obiecanka brzmie moe: "Jesli to jest wam potrzebne, to oczywicie zrobimy, mimo iz inni tego nie maj". Obietnice adresowane s zwykle do osób z kierownictwa podejmujcych decyzje o wyborze, natomiast póniej w kontraktach nie zawsze pamita si o tych zobowizaniach.) lub jedynie koncepcji. Czsto ju na podstawie kontaktów dotyczcych programu i organizacji wizyt referencyjnych mona zorientowa si o sprawnoci organizacyjnej i merytorycznej znajomoci tematyki przez oferenta integratora. Jeli oferent jest tylko dostawc-porednikiem, to korzystna moe by równie wizyta w firmie bcej twórc systemu, gdy wówczas mona zorientowa si w rzeczywistym potencjale i kwalifikacjach personelu, który bdzie wspomaga nabywc w trakcie wdraania i modyfikacji aplikacji. Problem, czy system ocenia wg wad czy zalet, pozostaje otwarty. Zapewne bardziej docenia naley zalety ni wady, chyba e usunicie wad wymaga gruntownych zmian w architekturze systemu i wady te powoduj, system nie spenia nadrzdnych wymaga. Jedn z typowych wad moe by brak kompleksowoci. Nie mona jednake stawia tutaj postulatu "wszystko albo nic!", gdy systemów naprawd kompleksowych pochodzcych od jednego wytwórcy jest jak na lekarstwo. Spraw naleoby w kontrakcie rozwiza w ten sposób, e jeli moliwe jest spenienie wymaga funkcjonalnych np. na zasadzie konsorcjum oferentów, dostawca-koordynator przejmuje na siebie obowizek integracji moduów zewntrznych, przynajmniej na poziomie gównych baz danych (klienci, rachunki, ksiga gówna). Jeli - aby mie skal porównawcz - wybierze si kilka systemów do oceny, to trzeba dysponowa 5-7 osobowym zespoem o odpowiednich kwalifikacjach bankowych, informatycznych i jzykowych, aby w rozsdnym czasie (np. 2-3 lat) przej drog od rozpoznania i sformuowania wasnych potrzeb do zawarcia kontraktu. Warto zaznaczy, e samo opracowanie szczegóowych wymaga w zakresie produktów bankowych (szczególnie w zakresie skarbowoci i operacji zagranicznych) i architektury systemu, moe okaza si zadaniem wymagajcym zatrudnienia konsultantów, którym trzeba duo paci i których trzeba umie wykorzysta!. Oczywicie wykorzystujc tych konsultantów, powinno si docenia równie wiedz i kwalifikacje wasnych pracowników. Nie od rzeczy mona na koniec sformuowa zalecenie, e w trakcie postpowania przetargowego kupujcy nie moe wypuci inicjatywy z rk i da si zdominowa przez sprzedajcego. Osign to mona pod warunkiem oddelegowania do pertraktacji kompetentnych osób oraz zatrudnienia niezalenych konsultantów. Kady temat bcy przedmiotem przetargu wymaga opracowania specyficznej dokumentacji przetargowej. Jedna z jej czci jest opracowywana przez bank i przeznaczona jest dla dostawców. Powinna ona obejmowa midzy innymi opis stanu komputeryzacji banku (platformy sprztowe i bazodanowe, aplikacje i wolumeny danych itp.), przedstawienie kadrowych moliwoci banku we wspóuczestniczeniu w realizacji przedsiwzicia, opis wymaga aplikacyjnych (funkcjonalnych) i technicznych ze strony banku, zapytania w sprawie potencjau i stanu finansowego oferenta, moliwego zakresu oferty, danie szczegóowego przedstawienia referencji, opracowania specyfikacji kosztowo-cenowej oraz harmonogramu realizacji, itp. Dokumentacja przedstawiana przez oferenta z reguy skada si z dwóch podstawowych czci: oferty technicznej (specyfikacji oprogramowania, sprztu i usug) i oferty handlowej (specyfikacja cen dla pozycji wymienionych w ofercie technicznej, harmonogram dostaw, czasokresy instalacji, testowania sprztu i oprogramowania, zakres pilotowego wdroenia (np. w centrali i 10 oddziaach), etapy patnoci, warunki wypowiedzenia kontraktu itp. Stopie ryzyka decyzji wyboru systemu informatycznego mona zminimalizowa koncentrujc si na nastpujcych obszarach krytycznych: zakres definiowania produktów i transakcji bankowych odpowiadajcy strategii biznesowej banku,
szeroki zakres zarzdzania relacjami z klientem, obejmujcy rónorodne kanay dystrybucji produktów, badanie zachowania si klientów, dostosowanie usug do segmentów klientowskich itp. wciwe proporcje pomidzy zakresem przetwarzania natychmiastowego (w trybie on-line i w czasie rzeczywistym) i wsadowego, gwarantujce satysfakcjonujcy klienta czas obsugi oraz zamknicie dnia bankowego w przyzwoitym czasie (np. 5-6 godzin), pena (nie tylko dualna) wielowalutowo, dostarczanie w czasie rzeczywistym informacji o pozycji finansowej klientów banku, obsuga potrzeb kierownictwa, w tym raportowania przepywu pieninego i zarzdzania ryzykiem, obsluga oddzialu w stanie off-line ( jako zabezpieczenie na wypadek awarii sieci telekomunikacyjnej), odpowiednio wysokie bezpieczestwo systemu (m.i. poprzez zabezpieczenie dostpu i tworzenie dokadnych ladow audytowych). Dokadne przetestowanie systemu jest niezbdne, gdy wiadomo i diabe tkwi w szczegóach. Na przykad czasem system tylko pozorne speniania wymagania funkcjonalne banku: obsuguje salda debetowe na rachunkach ROR bez zrónicowanego liczenia ujemnych odsetek (w zalenoci od okresu zalegania ze spat skredytowanego salda) raportuje przepyw pieniny metod memoriaow (wg dat ksigowa) a nie kasow (wg momentu wpywu przychodów i wydatkowania kosztów) nie ma procentowego naliczania opat transakcyjnych w momencie wprowadzania transakcji wielowalutowo systemu sprowadza si do tzw. walutowoci dualnej lub wielowalutowych ekranów kasjerskich (ale bez przeszacowa walutowych i samobilansujcych si ksig walutowych) nie dopuszcza si wybierania odsetek po kapitalizacji (np.w cigu "n" dni) nie ma reklasyfikacji rachunków przypadku obnienia salda poniej minimum przewidzianego dla danej waluty obsuguje transakcje dilerskie ale nie prowadzi limitów dla poszczególnych dilerów i walut obsuguje papiery wartociowe ale nie takie jakimi operuje bank niby jest zorientowany na klienta, ale finansow pozycj klienta uzyska mona dopiero w trakcie zamykania dnia a nie w czasie rzeczywistym System powinien by operowalny czyli atwy do utrzymania i obsugi. Przez operowalno systemu rozumiemy atwo utrzymywania oprogramowania i baz danych, podatno moduów aplikacyjnych na ntegracj z pakietami pochodzcymi od innych wytwórców, przejrzysto funkcjonaln oraz atwo dostosowania czynnoci (menu) do obsugi poszczególnych stanowisk pracy w bach bankowych. System bankowy zasuguje wic na miano nieoperowalnego, gdy jego uytkownicy bankowcy b mie kopoty ze zrozumieniem funkcjonalnoci programów, za informatycy nie b w stanie ciwie administrowa systemu wskutek jego zawiej i nie udokumentowanej architektury. Jednym z wymogów operowalnosci jest kontrolowalno spójnoci systemu. Im wiksza zono systemu i bsza jego parametryzacja, dokonywana przez administratorów i przez samych uytkowników, tym bardziej system powinien by wyposaony w mechanizmy automatycznego wykrywania ewentualnych wewntrznych sprzecznoci, braku obligatoryjnych tablic, braku integralnoci danych (np. zerwane poczenia adresowe pomidzy powizanymi rekordami) itp. Bez takiego podparcia trudno jest system przetestowa w peni na etapie wdroenia i gwarantowa jego bezbdno podczas przetwarzania (gdy np. pojawi si nietestowane kombinacje parametrów lub nietestowane funkcje). Podane jest dla stabilnoci systemu, aby na przykad w ramach procedur otwierania dnia uruchamiany by specjalny przebieg testujcy spójno systemu (aby nieoczekiwane run-time errors nie pojawiay si w trakcie obsugi klientów). Brak przejrzystej architektury systemu lub braki w jej udokumentowaniu mog by przyczyn powanych trudnoci w ustabilizowaniu systemu po wprowadzeniu zmian autorskich i przez programistów bankowych.
Im bardziej skomplikowana jest architektura systemu, tym wiksza wystpuje potrzeba posiadania dokumentacji eksploatacyjnej, obejmujcej opisy moduów, baz danych, produktów, struktury katalogów w pamici dyskowej, funkcji programów, postpowania w przypadku pojawienia si bdów przetwarzania lub utraty danych, administrowania bazami danych, ustawiania parametrów dla systemu operacyjnego itp. Istotnymi czciami takiej dokumentacji s równie instrukcje dla kocowego uytkownika (gównie dysponenta i kasjera) w zakresie obsugi poszczególnych typów rachunków oraz instrukcje tzw.zamykania/otwierania dnia. Istotnym zagroeniem dla bezpieczestwa systemu mog by nieudokumentowane (w menu systemu oraz dokumentacji uzytkowej) operacje, uruchamiane bezporednio z linii komend (np. dotyczce transferu rachunków bankowych od jednego klienta do drugiego) lub/i nie pozostawiajce ladów audytowych. Do najbardziej istotnych zagadnie rzutujcych na operowalno naley technologia utrzymywania baz danych (uwzgldniajc stopien rozproszenia, replikacji, backupów), praca oddziaów w warunkach zerwania cznoci teletransmisyjnej oraz technologia zamykania dnia. W ramach zamykania dnia naley przewidzie reorganizacje baz danych (gdy spada efektywnoc przetwarzania np. wskutek zbytniej fragmentacji, nieoptymalnej struktury indeksów) i procedury postpowania w przypadku awarii ( odzyskiwanie danych, przeczanie pracy na orodek rezerwowy, okresowe czyszczenia, naprawa spójnoci, przetwarzanie z datami wstecznymi, cofanie przetwarzania wsadowego do okrelonych kroków itp. Innym powodem zaburze podczas wdraania i eksploatacji systemu moe by niewciwy system wprowadzania zmian do systemu przez zespó autorski, polegajcy albo na niedostatecznym testowaniu u siebie skutków zmian (co oznacza przerzucanie tego obowizku na programistów banku) albo na czstym przekazywaniu zbyt wielu drobnych zmian zamiast ich komasowania ze zmianami powaniejszymi i okresowego przekazywania w postaci nowej wersji systemu. Polepszenie operowalnoci systemu bank moe osign poprzez: zagwarantowanie w kontrakcie dokumentacji eksploatacyjnej dla kocowych uzytkowników oraz administratorów systemu dokadne rozgraniczenie w systemie - np. poprzez prawa dostpu - elementów rdzenia systemu (w zasadzie zmienianych jedynie przez autorów), elementów kastomizowalnych i zasad konstrukcji elementów, które mog by swobodnie dodawane przez bank uytkujcy) usunicie z systemu nadmiarowoci funkcjonalnej, o ktorej z góry wiadomo, e nie znajdzie zastosowania w ogóle (z powodu rónic systemu konstytucyjno-prawnego) lub w cigu najbliszych kilku lat zastosowanie organizacyjnych i funkcjonalnych rodków definiowania produktów bankowych (w tym zindywidualizowania uprawnie) oraz pomiaru ich ryzyka bankowego. Spojrzenie krytyczne na dostawców Zapewnienia firmy bcej integratorem i dostarczy rozwizanie pod klucz czyli wykona zadania kastomizacyjne i integracyjne oraz wdroeniowe s wiarygodne tylko wówczas jeli firma ta dysponuje dowiadczeniem, wiedz, ludmi oraz rodkami finansowymi do realizacji tej obietnicy. S wtedy egzekwowalne, jeli zostay w kontrakcie wyspecyfikowane zadania do wykonania oraz ich koszt ograniczono np. ryczatow kwot, patn zaliczkowo a gównie po wykonaniu wszystkich zada (inaczej rodki finansowe zosta mog przedwczenie wykorzystane bez realizacji caci ). Wiarygodne informacje o dostawcy i wykonawcy kontraktu uzyskuje si przede wszystkim poprzez szczegóowo zaplanowane pobyty u nich na miejscu oraz u ich klientów. Przedmiotem wywiadów jest aktualny kapita i dochodowo dostawcy, liczba specjalistów zatrudnionych w pracach projektowoprogramistycznych, stosowanie nowoczesnych narzdzi budowy aplikacji oraz powizania partnerskie ze specjalistycznymi firmami software owymi (gwarantujcymi odpowiednia jako wykonania zonych zada typu architektura klient-serwer), sposób kierowania rozwojem aplikacji (w tym testowania zmian) oraz jej dokumentowania, proporcje zatrudnienia pracowników produkcyjnych w stosunku do pracowników marketingu i sprzeday, dorobek wdroeniowy i liczba pracowników zaagaowanych do prac wdroeniowych oraz technicznego wsparcia, rodki obsugi klientów (np. zdalny elektroniczny help-desk, sposób dystrybucji zmian i ulepsze oprogramowania), informacje o szybkoci reagowania na bdy aplikacji, skala podjtych prac badawczo-rozwojowych (oby nie za dua, gdy wtedy odbywa si to kosztem obsugi sprzedanych systemów), obcienie firmy w zakresie konserwacji systemów ju wdroonych oraz zaangaowanie firmy w przetargach, moliwy stopie odpowiedzialnoci finansowej za straty banku wynike z bdnego dziaania oprogramowania itp. Wana jest informacja, czy moliwe jest bezpatne uzyskanie kodu ródowego w przypadku bankructwa lub przejcia przez inn firm.
Poniewa dobry system bankowy powinien obsugiwa nie tylko typowe produkty bankowe lecz równie dostarcza now wiedz bankow, istotnym elementem oceny dostawcy jest jego zdolno do rozwijania systemu od strony funkcjonalnoci bankowej (jeli w cigu ostatnich lat w oferowanym systemie nie nastpiy adne tego typu zmiany, mona wtpi czy w przyszci z inicjatywy dostawcy - w ramach wersji standardowej - bdziemy otrzymywa wzbogacane funkcjonalnie wersje systemu). Jak organizowa przetarg Podstawowym pytaniem, jakie powinien zada sobie bank, jest jak zagwarantowa obiektywno oceny i wyboru. Przede wszystkim naley wiedzie dlaczego (cele biznesowe i technologiczne) kupujemy nowy system. Niezbdne jest wic posiadanie wytycznych od kierownictwa banku (jakich korzyci oczekuje i na jakich usprawnieniach mu szczególnie zaley). Zdoby rozeznanie na rynku oferowanych systemów i pozna dowiadczenia (nie uczmy si na wasnych dach) innych banków. Zasady oceny punktowej trzeba opracowa przed rozesaniem zaprosze do skadania ofert (RFP - request for Proposal), aby nie by posdzonym o dopasowywanie ich pod ktem niektórych dostawców. Do zespou oceniajcego powinni by oddelegowani kompetentni i nieprzekupni specjalici biznesowi (do oceny funkcjonalnoci) i informatycy, znajdujcy wspólny jzyk ze sob. Wynagradzani dodatkowo mog by nie tyle ograniczon odgórnie wspóln pul (wyzwala czasem reakcj blokowania liczby osób do pracy w zespole) ile nagrodami indywidualnymi. W skad zespou konsultantów nie powinny wchodzi osoby powizane z oferentami wzgldnie z ich konkurentami (zdarza si, e doprowadzaj do uniewanienia przetargu i potem proponuj innych). Wybór systemu odbywa si moe kilkuetapowo. Na przykad najpierw przeprowadzi mona postpowanie przedprzetargowe, którego celem jest rozpoznanie rynku dostawców, integratorów i nastpnie wybór takich, do których zostanie wysana proba o nadesanie oferty. Sam przetarg moe odbywa si w trybie ograniczonym (bank wybiera uczestników) lub nieograniczonym. W przypadku przetargu na system kupowany np. z kredytu banku wiatowego obowizuj zasady narzucane przez ten bank i samo uruchomienie kredytu odbywa si moe dopiero na wniosek rzdu. Fazy wyboru w trakcie przetargu mog by nastpujce : - weryfikacja zgodnoci oferty (struktury, formatu i zawartoci) z wymaganiami przetargowymi - preselekcja poprzez sprawdzenie listy kontrolnej (check-list) czy system spenia podstawowe wymagania - ocena (zwykle punktowa) ofert nie wykluczonych. W zaproszeniu do zenia oferty bank formuuje wymagania aplikacyjno- funkcjonalne oraz narzuca szczegóowy ukad specyfikacji ofertowej, zajmujcy zwykle wiele stron. Tutaj ograniczymy si niektórymi przykadowymi danymi dla hurtowni danych. Pomijamy tutaj takie sprawy formalne jak wpis do rejestru sdowego firmy i finansowy status oferenta, wysoko wadium, prawa asnociowe, patentowe i licencyjne oraz sprzedane (jeli oferent nie jest autorem lub producentem), gwarancja bankowa realizacji kontraktu, tryb patnoci, waluta, jzyk dokumentacji i zyk negocjacji, podatki i opaty, etc. Oferta na dostaw hurtowni danych powinna od strony technicznej zawiera co najmniej nastpujce informacje: - zapewnienie realizacji zada tematycznych (np. zarzdzanie przepywem pieninym w skali banku, zarzdzanie ryzykiem, kontrolling, itp.) wymienionych w zaproszeniu do zenia oferty. - opis sprztu i oprogramowania dopasowanego do realizacji zada. - ograniczenia dotyczce baz danych: maksymalny wolumen bazy danych, maksymalna liczba baz, maksymalna liczba tablic w bazie, maksymalna liczba kolumn w tablicy, maks.dugo wiersza, maks.dugo zapytania (w bajtach) - ograniczenia dotyczce baz wielowymiarowych (maksymalne wolumeny, liczba wymiarów, maksymalna liczebno liczba wartoci - wymiaru, maksymalna liczba kostek wielowymiarowych, wspólne repozytorium obiektów czy izolowane dla kadej kostki)
- sprawno technologiczna hurtowni danych (czynniki rónicujce czasy odpowiedzi na zapytania, czasy adowania danymi, metody optymalizacji zapyta, metody kompresji danych zmniejszajce zapotrzebowanie na pami dyskow, zrównoleglone przetwarzanie itp.) - konfiguracja sprztu oraz oprogramowanie systemowe (systemy operacyjne, oprogramowanie narzdziowe, zyki programowania) - skalowalno oraz metody i koszty jej realizacji - pomiary wydajnosciowe (benchmarki) QppD ze szczególnym uwzgldnieniem wolumenu danych dla rónych wielkoci baz danych: 1GB,10GB,30GB,100GB,300GB i 1 TB - rodzaje analizy wielowymiarowej oraz wizualizacji dostpne w oferowanych narzdziach OLAPowych - metody realizacji inteligentnej eksploracji danych (data-mining) - opis narzdzi administrowania - opis repozytorium metadanych - rodzaje moliwych interfejsów - otwarto w stosunku do platform komputerowych (systemów operacyjnych i hardware'u) - narzdzia czyszczenia i transformacji danych - bezpieczestwo danych Oferta powinna specyfikowa zakres usug wykonawcy (z zaznaczeniem stopnia wspóudziau banku): - Wspomaganie modelu biznesowego - Projekt i oprogramowanie aplikacyjne hurtowni danych - Konsulting biznesowy - Konsulting software'owy - Funkcje integratora rozwizania - Dostawa sprztu - Dostawa oprogramowania bazy danych - Dostawa pozostaego oprogramowania - Techniczne wsparcie sprztu i oprogramowania - Prace wdroeniowe: w zakresie jakich hurtowni danych i datamartów - Usugi szkoleniowe - Serwis gwarancyjny i pogwarancyjny - Inne usugi: przekazywanie ulepsze oprogramowania (tzw. update y) i sprztu. Referencje wdroeniowe powinny by podawane oddzielnie dla kadej instytucji, w której dokonano wdroenia, w nastepujcym ukadzie: Informacje ogólne a)dokadna nazwa i adres siedziby firmy referencyjnej, b)liczba oddziaów instytucji referencyjnej, c)wielko bazy danych, dzienne iloci gromadzonych i przetwarzanych danych d)nazwa wdroonego systemu i szczegóowy opis zakresu wdroenia (zdarza si, e z zakupionej caci wdraa si tylko fragment akuratnie przydatny jako uzupenienie innej podstawowej aplikacji) e)nazwiska, adresy i telefony osób, które udostpni informacje na temat przebiegu wspópracy z oferentem f)zaangaowanie wykonawcy/oferenta w realizacji zada (np. w zakresie wsparcia technicznego) g)stopie pokrycia potrzeb funkcjonalnych przez system (szczególnie w stosunku do deklaracji oferenta) liczba osób ze strony oferenta i czasokres zaangaowania zakres wykonanych prac (konsulting, projekt, oprogramowanie,dostawa sprztu, wdroenie itp.) w przekroju poszczególnych hurtowni danych i datamartów. platformy sprztowe (komputery i systemy operacyjne), na których zrealizowano wdroenie. Czas reakcji na usterki oprogramowania i awarie sprztu. Szczegóowa specyfikacja jest niezbdna aby w ofercie byo jak najmniej generalnych deklaracji. Jednake bez wzgldu na szczegóowo zawsze istnieje ryzyko decyzyjne. Ryzyko mona traktowa jako prawdopodobiestwo wystpienia ujemnych skutków, zagroenie lub niepewno osignicia zamierzonych celów. Stopie ryzyka jest tym wikszy im bardziej decydenci w banku wierz w optymistyczny wizerunek systemu prezentowany przez dostawców. Pewnym zabezpieczeniem na wypadek ryzyka jest zapewnienie sobie kar umownych ze strony dostawców, lecz oni rzadko na to si godz i nie zawsze wyrówna to straty banku zwizane np. z nieudanym wdraaniem systemu lub dsz awari.
Podsumowanie Jednym z celów oceny systemu jest minimalizacja ryzyka kupowania kota w worku. Brak starannej weryfikacji systemu przed zawarciem kontraktu moe sprawi, e kupowany system robi wszystko ale nie tak jak spodziewa si uytkujcy go bank czyli robi wszystko i nic (robi wszystko ale nie wg takich algorytmów i przepisów bankowych jakie stosuje kupujcy go bank). Oceniajcy musz by uodpornieni propagand sukcesu i na deklaracje, e brakujace elementy s w kocowej fazie opracowania i na pewno b gotowe na czas Naley pamita, e od realizujcych kontrakt dostawców zaley wiele, ale nie wszystko. Przyczyn nie wywizania si dostawcy z zobowiza moe by równie brak dostatecznej wspópracy ze strony banku podczas kastomizacji *dostosowania lokalizacji) i wdraania systemu. W wyborze systemu wystpuje sprzenie aspektów biznesowych i informatycznych, angaowany jest nie tylko kapita ale przede wszystkim wiedza fachowa. Dobrze wic jest jeli dziki nowemu systemowi bank bdzie móg nie tylko ulepszy to co posiada, lecz zaproponowa nowe produkty, nowe kanay i wysz kultur biznesow. Brak odpowiednich decyzji komputeryzacji banku jest ryzykiem najwikszym, gdy pozbawia bank szans radykalnego usprawniania zarzdzania i obsugi klienta, zmniejszajc szanse przetrwania na wymagajcym rynku bankowym. Popiech nie jest zalecany, ale czasem na podjcie kluczowych decyzji czeka si niepotrzebnie latami. Grzechem jest wic brak strategii komputeryzacji czyli komputeryzacja jak leci poprzez nagromadzenie komputerów osobistych (najlepiej aby na kadym biurku sta komputer co bdzie wiadczy o nowoczesnoci firmy) oraz wielu najróniejszych programów w sumie nie stanowicych logicznej i technologicznej caci. Brak wciwych decyzji wynika moe wskutek tradycyjnie silnie zakorzenionego oporu przeciwko zmianom. Przewanie jest to opór ukryty, dlatego trudny do pokonania. Czsto wystpuje na wszystkich szczeblach. W naczelnym kierownictwie jest to opór przeciwko zmianom organizacyjnym oraz zmianie stylu pracy (niech uywania nowych narzdzi w procesach decyzyjnych), a niekiedy te unikanie ryzyka. W kierownictwie operacyjnym opór przejawia si poprzez wykazywanie zajtoci uniemoliwiajcej szkolenie w zakresie nowego systemu, boja przed zmianami kadrowymi (zastpienie przez modszych i bardziej zaznajomionych z technik komputerow), obawa niemonoci kontroli i oceny personelu w nowych warunkach, irytacja wobec zbyt szybkich zmian organizacyjnych, itp. Personel wykonawczy wykazuje instynkt samozachowawczy w postaci bojani przed zwolnieniem z pracy (z reguy jednym z celów komputeryzacji jest redukcja etatów) i utrat dotychczasowych kwalifikacji oraz wobec nowej techniki ( czy poradz sobie? ). Skutki oporu s rozmaite. Przede wszystkim jest to odwlekanie decyzji (czasem do przysowiowej emerytury) i tendencja do akcentowania wad przyszego systemu przy równoczesnym pomijaniu zalet. Tak czy owak s fatalne dla rozwoju banku. Dr Zygmunt Ryznar