Wielkie systemy, wielkie problemy

Przemiany, które dokonały się w Polsce pod koniec lat 80., wywarły ogromny wpływ na świat IT w sektorze bankowym. Do tego momentu sektor ten ograniczał się do monolitu kilku banków państwowych spełniających ściśle przypisaną im rolę w systemie nakazowo-rozdzielczym.

Przemiany, które dokonały się w Polsce pod koniec lat 80., wywarły ogromny wpływ na świat IT w sektorze bankowym. Do tego momentu sektor ten ograniczał się do monolitu kilku banków państwowych spełniających ściśle przypisaną im rolę w systemie nakazowo-rozdzielczym.

Powstanie banków komercyjnych wydzielonych z NBP oraz swoboda w powstawaniu nowych instytucji finansowych spowodowały ogromne zapotrzebowanie na określenie ich strategii IT i wyboru lub budowy własnych rozwiązań informatycznych zdolnych obsłużyć produkty bankowe, które banki zamierzały oferować. Historia ta była tylko powtórzeniem procesów decyzyjnych dotyczących wyborów dużych systemów informatycznych na Zachodzie, gdzie była jednak bardziej rozciągnięta w czasie.

Wybór rozwiązania IT decydującego o sprawności operacyjnej wielkiej instytucji jest procesem trudnym, niosącym duże ryzyko. Jak każde, także i to ryzyko musi być we właściwy sposób monitorowane i minimalizowane tam, gdzie jest to możliwe. Aby móc podejść w sposób systematyczny do tego procesu, należy rozważyć krytyczne czynniki sukcesu takiego przedsięwzięcia. Nie jest ich wiele, ale spełnienie ich jest niezwykle trudne. Są to: kompletność i adekwatność wymagań użytkownika; niezależna weryfikacja zbudowanych wymagań; istnienie skalowalnej platformy systemowej dla danej klasy rozwiązań; przeprowadzenie wiarygodnych testów wydajności; dostępność wsparcia na rynku; rzeczywiste wsparcie najwyższego kierownictwa; obiektywny proces wyboru, oparty na kryteriach merytorycznych; właściwa organizacja projektu; wreszcie posiadanie odpowiednich zasobów do sfinansowania wieloletniego projektu.

Istnieje wiele dodatkowych czynników, które mogą spowodować, że wybrana droga może prowadzić do sukcesu lub klęski. Istnieją też wyjścia pośrednie, których nie można określić jednoznacznie jako stanu sukcesu lub klęski, i z takimi rezultatami mamy najczęściej do czynienia. Jak bowiem opisać projekt, który co prawda doprowadził do implementacji 60% założonej funkcjonalności - choć tej potrzebnej do obsługi banku nie uwzględniono w ogóle - ale projekt trwał cztery razy dłużej niż założono, a koszty przekroczono dwukrotnie? Nie są to przykłady rzadkie, a błąd można popełnić w każdej fazie projektu. Instytucje finansowe nie są zainteresowane ujawnieniem szczegółów realizowanych projektów, a w szczególności problemów, które pojawiły się podczas ich realizacji, czy też braków funkcjonalnych wdrożonych systemów, których usunięcie mogłoby wymagać konwersji na kolejny system, a takie przypadki również miały miejsce w Polsce.

Bliźniacza referencja

W wielu przypadkach można poprowadzić stosunkowo bezpiecznie projekt, jeśli lista produktów jest dobrze zbudowana i stabilna, a instytucja osiągnęła wolumen produktów i klientów nie ulegający większym zmianom. W takich warunkach dobrym punktem odniesienia jest zbliżona instytucja, obsługująca podobną lub większą liczbę klientów i, co ważne, wykonująca podobne operacje na zbliżonej liczbie produktów, które mają być obsługiwane docelowo. Można wówczas stosunkowo bezpiecznie założyć, że wizyta referencyjna ma sens, a fakt poprawnego działania systemu w analogicznej instytucji z dużym prawdopodobieństwem powtórzy się przy kolejnej implementacji.

Istotne jest również, czy wybrano odpowiednie parametry do porównania w bliźniaczej instytucji. Pozorne ich podobieństwo może łatwo doprowadzić do fałszywych wniosków.

Znany jest mi przypadek, gdy w trakcie ewaluacji systemu dla banku, jako bank referencyjny wskazano instytucję mającą co prawda zbliżone liczby: transakcji, rachunków i klientów, ale prowadzącą wyłącznie działalność depozytową i udzielającą kredytów ratalnych. Można było to łatwo rozpoznać po charakterystycznej strukturze uproszczonego bilansu nie wykazującej praktycznie operacji związanych z bardziej złożonymi produktami, szczególnie na rynku międzybankowym. W trakcie wizyty referencyjnej okazało się ponadto, że bank nie dokonał całkowicie konwersji na nowy system, a księgę główną nadal przechowuje w starym.

Aby oddać lepiej naturę problemu, oto kilka sytuacji, które wydarzyły się w bankach umownie określonych jako A i B.