Czy systemy core to przeżytek?

W debacie uczestniczyli Maciej Tomczyk, Country Managing Director, DXC Technology oraz Michał Regiński, Application Services Practice Manager, DXC Technology, przedstawiciele partnera debaty – firmy DXC Technology oraz reprezentanci sektora bankowego: Piotr Bednarski, dyrektor Pionu Rozwoju i Utrzymania Aplikacji, PKO Bank Polski; Piotr Długaszek, IT Lead – główny architekt, Pion CIO / Centrum Eksperckie Architektury i Strategii IT, ING Bank Śląski; Paweł Michalski, Head of Architecture, BLIK; Piotr Pietrzak, Tribe Leader Core Banking Platforms, Erste Bank Polska; Jacek Presz, dyrektor Departamentu Informatyki i Telekomunikacji, Bank Ochrony Środowiska; Włodzimierz Warych, dyrektor, Departament Rozwoju Aplikacji, Zespół Projektowania Rozwiązań Centralnych, Bank Millennium.

Gospodarzem spotkania był Paweł Minkina, redaktor naczelny Miesięcznika Finansowego BANK.

Czy systemy core’owe to dzisiaj core’owy temat w sektorze bankowym? Czy powinien być na ustach wszystkich bankowców? A może to taki temat, który często pojawia się podczas konferencji i wydarzeń technologicznych, ale nie należy go uznawać za priorytet?

Piotr Długaszek
IT Lead – główny architekt, Pion CIO / Centrum Eksperckie Architektury i Strategii IT, ING Bank Śląski

Piotr Bednarski
dyrektor Pionu Rozwoju i Utrzymania Aplikacji, PKO Bank Polski

Piotr Długaszek: Jest to bardzo ważny temat, natomiast na pewno nie core’owy. Są w bankowości dużo ważniejsze tematy, chociażby czysto biznesowe. Jednak z naszej perspektywy to jest bardzo ważne zagadnienie technologiczne. System działa doskonale, nie mamy z nim większych problemów, więc z perspektywy biznesowej jego wymiana niewiele wnosi. Z kolei z perspektywy technologicznej nazwałbym to zarządzaniem ryzykiem. Chodzi o to, by za kilka czy kilkanaście lat nie mieć problemu, bo jeśli core ma na przykład 30 lat, to ludzie, którzy go znają, odchodzą na emeryturę, może się zatem w pewnym momencie okazać, że już nikt kompletnie nie wie, co tam się dzieje.

Piotr Bednarski: Porównując się z tym, z czym borykają się większe banki od nas, nie mamy powodów do zmartwień. U nich pracują systemy, które mają 30 czy 40 lat, ale nawet tam – patrząc z perspektywy biznesu – wszystko działa. Nasze systemy są znacznie młodsze, dlatego nie jest to problem core’owy. Natomiast te systemy się starzeją, a wiemy, że technologii nie modernizuje się szybko, więc kiedyś trzeba to zacząć.

Paweł Michalski
Head of Architecture, BLIK

Piotr Pietrzak
Tribe Leader Core Banking Platforms, Erste Bank Polska

Michał Regiński
Application Services Practice Manager, DXC Technology

Piotr Pietrzak: To nie jest taka prosta sprawa, jak w przypadku innych, mniejszych systemów, które jesteśmy w stanie zmodernizować czy wymienić w ciągu roku. Patrząc na doświadczenia światowe, to wymiana systemów core trwa od 5 do 7 lat, a same przygotowania drugie tyle. Oznacza to, że właściwie jesteśmy w dobrym momencie, żeby o tym rozmawiać i wypracowywać strategiczne podejście. Natomiast czy sam temat jest core’owy, to zapewne zależy od banku. Trzeba odpowiedzieć sobie na pytania, na ile mój system adresuje potrzeby klienta wewnętrznego i zewnętrznego, czy jest bezpieczny i tak dalej. I wówczas można odpowiedzieć sobie na pytanie, czy mamy rok, dwa, czy pięć lat, a może jeszcze więcej. To zależy od wielu czynników i powinno wynikać z assessmentu, który pokazuje tak naprawdę realne problemy w danym banku z systemem i jego otoczeniem.

Michał Regiński: Dyskutujemy o systemach core’owych, które mają niekiedy 30 lat i więcej. Przechodziły w tym okresie niejedną transformację i modernizację. Zmiany te mogły doprowadzić do konsolidacji kluczowych funkcji systemu, takich jak np. księga główna czy kartoteka klienta przy jednoczesnym wyniesieniu pozostałych funkcjonalności poza system główny. W takim scenariuszu dobrze zaprojektowana warstwa integracyjna umożliwia dziś sprawny rozwój nowoczesnych usług bazujących na kanałach mobilnych czy webowych. Mogło się jednak zdarzyć, że rozwój systemu przebiegał inaczej i pogłębiał jego wewnętrzną złożoność oraz poziom zależności, dodawane do niego były kolejne funkcje biznesowe. W efekcie przez lata nawarstwiał się dług technologiczny, który dzisiaj stanowi barierę w dalszym rozwoju banku lub istotnie podnosi koszty dostosowania do wymogów regulacyjnych.

Włodzimierz Warych
dyrektor, Departament Rozwoju Aplikacji, Zespół Projektowania Rozwiązań Centralnych, Bank Millennium

Maciej Tomczyk
Country Managing Director, DXC Technology

Włodzimierz Warych: Banki zaczynają wykonywać pewne kroki związane z modernizacją core, ale często pojawia się to w zupełnie innej perspektywie. U nas była kiedyś taka koncepcja, że core odpowiadał za wszystko, w tej chwili dążymy właśnie do tego, żeby te elementy, które są frontem, czy są związane z biznesem, wynosić poza system.

Piotr Pietrzak: A czym jest core? Trzeba to zdefiniować. Czy jest to ta część, która liczy odsetki? Prowadzi rachunki? Zrobiliśmy taką analizę, i okazało się, że ponad 50% funkcjonalności systemu, nie jest core. To elementy nierozwojowe, albo nie działające biznesowo, ale ciągle siedzą w systemie. Likwidacja takiego obciążenia z jednej strony ułatwia działanie systemu i daje biznesowi możliwość szybszego realizowania projektów poza głównym systemem, z drugiej strony powoli przygotujemy się do tego, żeby za 5-7 lat znacznie łatwiej zrobić modernizację lub konwersję na nowy system.

Kiedyś wszystko wrzucaliśmy do core, bo tak było wygodniej, bo była jedna platforma. Ale świat się zmienia, zmienia się architektura, zmieniają się technologie, i dzisiaj wygląda to zupełnie inaczej.

A jeśli na zarządzie pojawia się taki temat, to kto musi podnieść rękę i powiedzieć, że fajnie by było zmienić system core? Zawsze to jest IT, czy być może taka sugestia i informacja dochodzi gdzieś z zewnątrz?

Piotr Pietrzak: U nas to ja poruszyłem sprawę ze swoim członkiem zarządu i zostałem poproszony o przygotowanie prezentacji i pokazanie tego na zarządzie. Ale tak naprawdę, ze względu na skalę to właściciel pochyla się nad takimi decyzjami. Jednocześnie przy udziale wszystkich stron trzeba zrobić assessment, bo w tej decyzji muszą uczestniczyć wszyscy. Jeżeli ktoś nie jest przekonany, to najzwyczajniej w świecie nie będzie to priorytetem w najbliższych latach i budżety zostaną skierowane na inne pozycje. A mówimy o ogromnych kwotach rzędu 300 czy 600 mln zł.

Z drugiej strony, czas takiej konwersji, czyli realizacji całego programu, trwa dłużej niż kadencja zarządu, dlatego najprościej mieć za sobą wszystkich i wtedy rzeczywiście jest łatwiej.

Maciej Tomczyk: Podam przykład jednego z globalnych banków amerykańskich, który może stanowić interesującą inspirację. W tej organizacji impulsem do modernizacji systemu core banking nie był dział IT, lecz sam biznes. Wraz z rozwojem inicjatyw związanych ze sztuczną inteligencją bank dostrzegł nowe możliwości rynkowe, dochodząc do wniosku, że pełne wykorzystanie potencjału AI wymaga modernizacji platformy centralnej. Celem nie była więc sama wymiana technologii, lecz stworzenie fundamentu umożliwiającego ­skuteczne wdrażanie i skalowanie rozwiązań AI w całej organizacji, a tym samym wykorzystanie nowych szans biznesowych oraz wzmacnianie przewagi konkurencyjnej. Skala oczekiwanych korzyści była na tyle znacząca, że program transformacyjny szybko uzyskał wysoki priorytet strategiczny, a nasz zespół zaangażowany w realizację tego przedsięwzięcia został w krótkim czasie wielokrotnie powiększony.

A jeśli zapadła już decyzja, to jakie główne problemy i na jakim etapie mogą się pojawić? Czy to kwestia kosztów? Czy być może kwestie pracownicze? A może jednak opór na linii biznesowej?

Piotr Długaszek: Problemem jest chyba bariera wejścia. Drobna zmiana mało kosztuje i zajmuje niewiele czasu, pieniędzy i zasobów ludzkich. Ale jakbyśmy chcieli to zbudować od nowa, to nagle się okazuje, że trzeba wynieść wielką domenę biznesową w inne miejsce, postawić to z boku i dopiero wówczas zrobić wymianę. I to jest duże wyzwanie, bo na takie działanie nigdy nie ma dobrego momentu. Poza tym okazuje się, że w pewnym momencie mamy dwa systemy – starego core i cały nowy ekosystem.

Jacek Presz
dyrektor Departamentu Informatyki i Telekomunikacji, Bank Ochrony Środowiska

Paweł Minkina
redaktor naczelny Miesięcznika Finansowego BANK.

Jacek Presz: Nie ma takiego gotowca, na którego moglibyśmy się przesiąść, bo wszystko co mamy zbudowane, to jest efekt wielu lat pracy i wielu uwarunkowań lokalnych. Do tego dochodzi istotny aspekt całej warstwy sprawozdawczo-regulacyjnej, która gdzieś tam jest schowana.

Piotr Pietrzak: Najważniejsze są oczywiście pieniądze, bo albo je mamy, albo nie. Poza tym, do tego projektu muszą być przekonani wszyscy, cały bank, i to od samego początku, a nie dopiero w momencie, kiedy pojawią się problemy. Biznes musi być zaangażowany od początku, z pełną decyzyjnością, również modyfikującą zakres projektu. To nie jest projekt technologiczny, bo starzeje się technologia, to jest projekt, który ma wspierać biznes.

I pozostaje jeszcze decyzja czysto techniczna – czy wymieniamy cały system na inny, czy inwestujemy w kilka różnych zintegrowanych modułów i na tym budujemy domeny biznesowe. A może w ogóle software as a service w chmurze. Jest mnóstwo rozwiązań.

Poza tym, trzeba pamiętać, że ludzie, którzy znają system odchodzą na emeryturę, a młodzi nie bardzo chcą się uczyć obsługi starego systemu, bo dzisiaj technologia działa zupełnie inaczej. Może więc AI jest rozwiązaniem?

Piotr Bednarski: A może fakt, że ludzie odchodzą i te kompetencje znikają nie jest problemem? Bo tak naprawdę ważne jest, żeby młodzi potrafili dobrze posługiwać się narzędziami. Przecież nie płacimy deweloperowi za to, że zna określony język programowania. Rynek poszedł do przodu i chodzi o to, by człowiek potrafił myśleć i odzwierciedlać problem biznesowy w systemie. Wydaje się, że dzięki technologii do tego właśnie dojdzie.

Piotr Pietrzak: Powinniśmy szukać i zachęcać przyszłych specjalistów, by byli specjalistami od systemów, używając nowoczesnych narzędzi, agentów i tak dalej; abstrahując od technologii. Efektem pracy ma być wynik w systemie. I nie trzeba patrzeć, czy pracownicy potrafią napisać najbardziej optymalny kod, bo AI już potrafi napisać optymalny kod. On robi też dokumentację lepiej niż my i nie narzeka. Więc ja rzeczywiście wierzę w to, dlatego powinniśmy szukać trochę innych ludzi niż dotychczas.

Jakie macie oczekiwania wobec dostawców rozwiązań? Czy znacie jakieś wzorcowe modernizacje? Ewentualnie takie, które wzbudziły w was zainteresowanie?

Piotr Pietrzak: Dostawca musi mieć przede wszystkim doświadczenie w innych częściach świata, ponieważ polski rynek jest za mały i za mało zmian było tu robionych, żeby powiedzieć, że mamy dobre doświadczenia z rynku krajowego. Ważne jest, żeby wyciągnąć przykłady i zobaczyć, co wyszło, a co nie wyszło. Czy nowe rozwiązania się przyjęły, czy się sprawdzają?

Piotr Bednarski: Potencjalny partner musi mieć zaplecze światowe. Poza tym, na pewno ważne jest, żeby tłumaczył od samego początku, jak się za to zabrać. Aby uczestniczył w całym procesie. Są takie firmy, które mają fajne doświadczenia, na przykład w Stanach czy w Kanadzie. Jesteśmy po wielu dyskusjach, i widać było, które firmy dzielą się doświadczeniami i podkreślają, że nie ma jednego uniwersalnego wzorca, tylko zawsze trzeba brać pod uwagę uwarunkowania lokalne, które muszą być uwzględnione. A nasze przemyślenia? Powiem tak, gryźć temat kawałek po kawałku, a nie całość od razu, bo uwarunkowania są bardzo różne – od organizacyjnych, budżetowych, czasu, strategii biznesowej, a nawet sytuacji politycznej. To wszystko ma wpływ na to, jak podejść do tematu.

Piotr Pietrzak: Doświadczenia innych to nie jest tajemnica, bo większość opisów można znaleźć nawet w mediach. Dobrym przykładem jest modernizacja systemów core w Erste Banku, bo odbyło się to globalnie i bardzo odważnie. Cała Grupa miała trzy systemy – osobny w Ameryce Południowej, osobny w Europie, a przy tym jeszcze inny w Polsce. Podjęto decyzję o globalizacji na poziomie jednego systemu. Nie wiem, czy jakaś inna korporacja zdecydowała się na taki krok.

Pierwszym ruchem było wyjście z systemów mainframowych do systemów opartych o tańsze rozwiązania, konwertując kod, wykorzystując takie mikrorozwiązania. To się udało i od razu mieli duże oszczędności, więc business case był od razu fajny. I to wyszło. Teraz realizują drugi etap – konwersja kodu bez zmian algorytmu, czyli tańsze rozwiązanie, wykorzystując inne tańsze platformy. Natomiast następnym krokiem będzie budowa systemu od zera, dla wszystkich lokalizacji. Powstanie jeden globalny system, w którym będą wspólne dla wszystkich rozwiązania, a jeśli pojawi się jakaś potrzeba lokalna, to dodana jest dodatkowa „warstwa”. Dotyczy to także całej koncepcji front-end. Ale do tego już na samym początku trzeba mieć zaangażowany biznes, bo bez tego w ogóle by nie wyszło. To rozwiązania techniczne, ale zmieniające przecież całkowicie podejście biznesowe.