Przejęcie przez VeloBank części detalicznej Citi Handlowego oznaczało przejście do niego ok. 0,5 mln aktywnych klientów; setek tysięcy, używanych przez nich, kart płatniczych; a także równoległe uruchomienie nowych usług w obszarach kart kredytowych, czy całkowicie nowych linii biznesowych z procesem uzyskania licencji od regulatora, tj. Biura Maklerskiego oraz Wealth Management. O tym, co zadziałało, gdzie pojawiły się problemy i dlaczego bank stawia na agentową AI rozmawiam z Przemysławem Kochem, CIO w VeloBanku. Po tablicy w Twoim gabinecie widać, że dużo się działo w czasie migracji. Jak oceniacie jej efekty po zakończeniu projektu? Tak, bardzo dużo się działo. Była to jedna z najbardziej skomplikowanych operacji tego typu na rynku. Oczywiście jej przebieg miał swoje pulsy i minusy. Minus to początkowe problemy z kartami? Minus to fakt, że część klientów napotkała na wyzwania w czasie onboardingu. Od strony migracji wykonaliśmy wszystko zgodnie z planem. W weekend migracyjny, czyli w 2 dni, wszyscy klienci zostali przeniesieni, podobnie jak ich produkty i salda. To była ogromna skala migracji danych - ich przyjęcie, przetworzenie, transformacja i wprowadzenie do naszego ekosystemu. Uzgodnienie finansowe wykonane w weekend migracyjny również potwierdziło, że nic nie „zgubiliśmy po drodze”. Niewielkie perturbacje pojawiły się później. Pierwszego dnia mieliśmy trochę problemów wydajnościowych, związanych z bardzo dużym zainteresowaniem klientów. Wówczas onboarding w VeloBanku z sukcesem zakończyło ponad 80 tys. osób. W kolejnych dniach skala była już znacznie mniejsza. Problemem okazał się jeden z komponentów środowiska IT. Była to centralna kartoteka klienta, zbudowana przez nas i wydzielona poza system centralny. Przed migracją przeprowadziliśmy kompleksowe testy wydajnościowe na środowisku migracyjnym. Nie wykazały one problemów. Niestety, zgodnie z prawem Murphiego, produkcja miała przejściowe problemy wydajnościowe, które usunęliśmy już pierwszego dnia po migracji. To pokazuje, że potrafimy reagować sprawnie. W jaki sposób przeprowadziliście migrację? Nie przejmowaliśmy od Citi Handlowego systemów, lecz wyłącznie dane. Wynikało to m.in. z tego że Citi Handlowy korzystał z centralnych systemów grupy, utrzymywanych przez zespoły z Singapuru czy Bangalore. Klient musiał więc po raz pierwszy zalogować się do serwisu VeloBanku. Mógł „wejść” do nas przez stronę Citi Handlowego, użyć dotychczasowych danych logowania, a następnie - już uwierzytelniony - zostać automatycznie przekierowany, aby dokończyć onboarding w naszym systemie bankowości elektronicznej. Utworzyć tam login i hasło, a także podpisać porozumienie regulujące przejście do banku. W tym procesie pojawiły się jednak wyzwania dotyczące kompletności i jakości danych. Jeśli np. w zmigrowanej kartotece klienta znajdował się nieaktualny numer telefonu, a do cyfrowego podpisania porozumienia potrzebny był kod SMS, proces nie mógł zostać zakończony. Podpisane porozumienie było wysyłane na adres email, a jak ten był nieaktualny to także klient potykał się na tym etapie. A wtedy kontaktował się z bankiem i słyszeliśmy pytania, skąd mamy takie dane, bo numer telefonu był już kilkukrotnie zmieniany, a adres mailowy jest nieaktualny i został założony jeszcze na domenie z lat 90-tych, która od lat nie funkcjonuje. Nie wszyscy klienci zapoznali się też z instrukcją onboardingu. Część rozpoczynała proces z zastrzeżonym numerem PESEL, co - zgodnie z przepisami - uniemożliwiało wykonanie czynności i podpisanie koniecznego porozumienia. Nie mogliśmy przy tym, ze względów regulacyjnych, komunikować klientowi dokładnej przyczyny problemu, więc kierowaliśmy go na infolinię. To były przede wszystkim wyzwania związane z onboardingiem i późniejszą obsługą klienta. Byliście pierwszym bankiem, który wykorzystał mObywatela do onboardingu. W mojej ocenie był to najbardziej przyjazny wariant. Klient od razu trafiał do nas. Nie przechodził przez stronę Citi Handlowego i nie korzystał ze starych danych uwierzytelniających. Mógł to zrobić za pośrednictwem mObywatela. Dzięki temu od razu logował się w VeloBanku i jednocześnie eliminowaliśmy problem, z którym się zetknęliśmy, czyli nieaktualnego dokumentu tożsamości. Oczywiście klient nadal musiał podpisać porozumienie, ale widział już wszystkie swoje produkty i salda, także w przypadku gdy miał już konto u nas. Na potrzeby migracji zbudowaliśmy także mechanizm konsolidacji kartotek. Zgodnie z wymogami regulatora oraz naszymi założeniami architektonicznymi dla jednego numeru PESEL może istnieć tylko jedna kartoteka. Dzięki temu po migracji klient widział produkty VeloBanku i Citi Handlowego na jednej zakładce. Sam byłem takim klientem. Celowo otworzyłem rachunki w obu bankach, aby aktywnie wziąć udział we wszystkich próbnych migracjach, weryfikując poprawność działania silnika migracyjnego oraz systemów źródłowych po migracji. Wyzwaniem dla niektórych migrowanych klientów była tzw. deduplikacja kartotek. Kilka odrębnych kartotek, prowadzonych dla tego samego klienta w Citi Handlowym, w procesie migracji było łączone do jednej. Klient po zalogowaniu przełączał się pomiędzy kontekstami detalicznym i firmowym. Gdy patrzę na statystyki onboardingu, ok. 86% klientów Citi Handlowego przeszło proces bez żadnych problemów. Kolejne 8% poradziło sobie w samoobsłudze. Z contact center skorzystało ok. 5%, a wizyty w oddziale wymagał 1%. Mówimy więc o około 6% klientów wymagających większego wsparcia. To właśnie ta grupa, choć relatywnie niewielka, wywołała dużą dyskusję w mediach społecznościowych. I im staraliśmy się pomóc jak najszybciej, bo też osobiście rozumiem jakim wyzwaniem jest utrudniony dostęp do kanałów cyfrowych swojego banku. Jestem pełen podziwu dla zespołu, który nieprzerwanie pracował, aby rozwiązać zgłaszane problemy i zapewnić klientom dostęp do ich bankowości. Jest jeszcze jedna sprawa, która wywołała spory wolumen reklamacji, a dotyczyła naliczenia opłat i prowizji za korzystanie z karty. Okazało się, że w Citi Handlowym istniała funkcjonalność, która służyła do indywidualnych zwolnień klientów z opłat. Było w niej ponad 200 tys. rekordów, w których zapisane były informacje o czasowym lub dożywotnim zwolnieniu klienta z opłat. Musieliśmy odtworzyć te dane w naszych systemach. W części przypadków opłaty zostały błędnie naliczone, ale zwróciliśmy je klientom. Teraz już wszyscy mają odwzorowane opłaty zgodnie z umowami zawartymi jeszcze w Citi Handlowym. Przejęliście też oddziały Citi Handlowego. To prawda. Weekend migracyjny nie oznaczał więc wyłącznie migracji danych. Obejmował również rebranding przejmowanych oddziałów i siedzib banku. Dopiero po decyzji o rozpoczęciu migracji, czyli w sobotę, uruchomiliśmy prace związane z przygotowaniem nowych lokalizacji do pracy w ekosystemie VeloBanku. W tym samym czasie podłączaliśmy naszą sieć do wszystkich oddziałów dawnej części detalicznej Citi Handlowego. Konfigurowaliśmy routery brzegowe i przełączniki wewnątrz placówek, a w przejętych komputerach instalowaliśmy nowe dyski. W każdej przejętej placówce od wczesnych godzin w poniedziałek nasi pracownicy Service Desk wydawali credentiale do logowania do domeny VeloBanku i zapewniali wsparcie w rozpoczęciu pracy. Wszystko po to, aby pracownicy już pierwszego dnia mogli zalogować się i pracować w naszych systemach. Wyzwań związanych z samym weekendem migracyjnym było więc dużo. O ile zwiększyła się liczba klientów VeloBanku? Mówimy o ok. 0,5 mln klientów. Zmigrowaliśmy ponad 600 tys. kartotek, ale część dotyczyła klientów nieaktywnych. Przed migracją VeloBank miał ok. 1,5 mln klientów. Trzeba także pamiętać, że klienci Citi Handlowego mieli nieco inną specyfikę działania niż dotychczasowi klienci VeloBanku. Ta transakcja nie polegała na prostym dublowaniu portfolio, ale na poszerzeniu spektrum naszej oferty. Klienci Citi Handlowego byli bardzo aktywni transakcyjnie w obszarze kart kredytowych. Zmigrowaliśmy ich ok. 0,5 mln i dołączyliśmy do portfela naszych usług. Wcześniej nasi klienci mieli ok. 50 tys. kart kredytowych. System kartowy musiał więc obsłużyć 10-krotnie większą liczbę kart kredytowych. Zwiększenie o 1/3 liczby klientów wymagało więc rozbudowy środowiska IT. To był bardzo wymagający projekt, realizowany w ambitnym horyzoncie 12 miesięcy. Umowę BTA - Business Transition Agreement - podpisaliśmy pod koniec maja 2025 roku, a dokładnie rok później byliśmy gotowi obsługiwać klientów po zakończonej migracji. W tym czasie dostosowywaliśmy ekosystem tak, aby efektywnie i wydajnie obsługiwać zwiększoną liczbę klientów. Rozbudowywaliśmy capacity, wymienialiśmy serwery, dokładaliśmy CPU i RAM tam, gdzie zidentyfikowaliśmy potencjalne, wąskie gardła, postawiliśmy infrastrukturę pod nowe linie biznesowe Biura Maklerskiego i Wealth Managementu, a także pod nowy system AML, który także na potrzeby obsługi połączonych baz klientów został wymieniony. Ważne, aby dodać tutaj, że prace te były wykonywane w nieprzewidywalnym otoczeniu. Ceny sprzętu szalały, kości pamięci DDR5 podrożały o 500%, a serwerów nawet o 300%. Do tego ważność pozyskiwanych ofert na sprzęt skróciła się do pojedynczych dni, a od dostawców nie raz słyszeliśmy, że mamy brać co jest, bo jutro będzie drożej. System kartowy to było główne miejsce, gdzie musieliście dołożyć „zasobów”? Zrobiliśmy to w wielu miejscach. Wymieniliśmy back-end bankowości internetowej i mobilnej, rozbudowaliśmy warstwę infrastrukturalną pod systemem centralnym. Nasz core system działa na serwerach IBM Power, więc kupiliśmy dodatkową maszynę, aby rozłożyć obciążenie. W obszarze kart kredytowych podjęliśmy decyzję o gruntownej przebudowie rozwiązania z naszym partnerem, ITCARD, procesującym transakcje kartowe. Budowaliście je czy kupiliście gotowe? Bazowaliśmy na naszej usłudze processingu wszystkich kart od ITCARD. Wspólnie musieliśmy jednak rozbudować system używany do procesowania transakcji. Karty kredytowe migrowane z Citi Handlowego miały specyfikę, budowaną przez kilkanaście lat. Wokół nich powstało wiele dodatkowych produktów, m.in. mechanizmy typu LOOP, A-LOOP, EPP, czy BALKON. Pozwalają one klientowi zarządzać zadłużeniem: rolować je, zwiększać limit czy rozkładać na raty transakcję obciążającą limit karty. Nie kupi się na rynku systemu czy usługi oferującej takie specyficzne produkty. Praktycznie od zera, na podstawie specyfikacji, budowaliśmy te produkty i powiązaliśmy je z działaniem kart w naszym banku. Citi nadal obsługiwał system kartowy z Singapuru? Pamiętam, że kiedyś tak było. Tak. To kolejny poziom złożoności całego przedsięwzięcia. Współpracowaliśmy z kilkoma ośrodkami w różnych strefach czasowych: Singapurem, Bangalore, Nowym Jorkiem i Londynem, gdzie znajdował się główny ośrodek zarządzania projektem migracji ze strony Citi Global. Musieliśmy skoordynować prace obejmujące rozpiętość stref czasowych sięgającą 12 godzin. Z kolei ekstrakcję danych z core systemów koordynował Singapur. Byliśmy z tym zespołem stale na łączach. Dane z systemów centralnych trafiały do nas, część była uzupełniana lokalnie, a następnie całość przechodziła przez silnik migracyjny, w którym wykonywaliśmy transformację i ładowanie danych. Czy poza systemem kartowym musieliście dobudować dodatkowe produkty, których nie było w VeloBanku? Jak wspomniałem, od zera uruchomiliśmy Biuro Maklerskie i segment Wealth Management, czy nowy system AML. Migrowaliśmy klientów wraz z produktami z tych linii biznesowych. Dlatego najpierw musieliśmy przygotować je po naszej stronie. W przypadku Biura Maklerskiego projekt obejmował także proces pozyskania licencji na jego działanie w VeloBanku, uruchomienie działalności, integrację z giełdą oraz KDPW i testy końcowe. W przypadku AML wdrożyliśmy nowe rozwiązanie. Nasze, własne nie było zbyt elastyczne. Mogło powodować problemy w obsłudze klientów Citi Handlowego. Działało bowiem zero-jedynkowo - klient albo był OK, albo też uznawany za klienta podwyższonego ryzyka. W tym drugim przypadku jego transakcje trafiałyby do dodatkowej weryfikacji - manualnej albo automatycznej. Podjęliśmy decyzję o wymianie systemu. Nowe rozwiązanie wykorzystuje silnik scoringowy, który uwzględnia różne poziomy ryzyka. Możemy ustawić granicę, po której przekroczeniu potrzebna jest dodatkowa weryfikacja. To również był system wdrażany w ramach tego projektu. Wszystko, jak wspomniałem, w 12 miesięcy. Nowy system na Giełdzie Papierów Wartościowych jeszcze nie działa, mimo zapowiedzi, że miało to się stać w listopadzie 2025 roku. To było dla nas dodatkowe wyzwanie. Musieliśmy uzgodnić z Citi Handlowym i naszym dostawcą to, aby system był gotowy do komunikacji z Giełdą Papierów Wartościowych zarówno przez stary interfejs UDP, jak i przez nowy WATTS. Wykonaliśmy testy jednego i drugiego rozwiązania. Giełda poinformowała jednak w międzyczasie o przesunięciu harmonogramu. Skoncentrowaliśmy się więc na starym interfejsie. To kolejny przykład tzw. „ruchomego celu” w projekcie. Rosnące w ciągu ostatniego roku ceny sprzętu zapewne nie pomagały w modernizacji środowiska IT? Rynek faktycznie nam przy tym nie pomagał. Dostawcy potrafili wypowiadać nam już podpisane umowy albo informować, że nie dostarczą sprzętu we wcześniej uzgodnionej cenie. Otrzymywaliśmy też terminy dostaw wynoszące od 50 do 60 tygodni, a my potrzebowaliśmy sprzętu w ciągu 2-3 miesięcy, aby zestawić środowisko dla nowych obszarów działalności i wykonać testy. Dotyczyło to zarówno pamięci masowych, jak i serwerów. Szukaliśmy więc alternatyw. Sprawdzaliśmy gdzie możemy kupić sprzęt, za jaką cenę, czy mieścimy się to w naszym budżecie. Przy odległym terminie dostawy sprawdzaliśmy też czy można sprzęt wynająć. Musieliśmy też sprzęt kupiony wcześniej do planowanego upgrade’u klastra bazodanowego przesunąć do tego projektu. Było to więc zarządzanie kryzysowe. Czy wykorzystanie zasobów w chmurze publicznej było jakąś alternatywą? Tam, gdzie mamy rozwiązania chmurowe, rozbudowywaliśmy istniejące środowiska. Cała migracja została jednak zrealizowana on-premise, w naszych serwerowniach. Dodatkowo musieliśmy przygotować w nich odpowiednio zabezpieczone środowisko, galwanicznie odseparowane od innych systemów i środowisk VeloBanku. Był to wymóg zdefiniowany w umowie BTA z Citi Handlowym. Bank ten weryfikował, czy podczas próbnych migracji dane trafiają wyłącznie do tego, odseparowanego obszaru. Po zakończeniu testów dane kasowaliśmy i musieliśmy potwierdzać ich usunięcie. Jaka była najcięższa rzecz w projekcie, pomijając problemy ze sprzętem? Każdego dnia pojawiało się coś nowego: braki zasobowe, zarówno ludzi, specjalistów i sprzętu; wyzwania z dobrym zdefiniowaniem luk i specyfikacji; dodatkowe warsztaty; mapowanie danych. Samo mapowanie było bardzo wymagające. Dane znajdowały się w jednym miejscu, zespoły odpowiedzialne za ich przygotowanie w drugim, a jednostki merytoryczne rozumiejące ich znaczenie jeszcze gdzie indziej. Zespół z Singapuru mógł powiedzieć: „mamy takie dane”, ale nie zawsze wiedział, co znajduje się w konkretnym polu. Kierowano nas do zespołów lokalnych w Polsce, a te z kolei nie zawsze mogły rozpoznać dane bez zobaczenia ich na ekranie systemu. Czasami dochodziliśmy do sytuacji przypominającej Reverse Engineering. Patrzyliśmy na dane klienta na ekranach Citi, a później szukaliśmy ich w zbiorach. Zdarzały się też błędy w ręcznym mapowaniu, które należało poprawiać podczas kolejnych próbnych migracji. Dodatkowo specyfika funkcjonowania Citi jest taka, że przy globalnych systemach używanych przez oddziały na całym świecie bardzo trudno było uzyskać zmianę. Jak w przypadku systemu kartowego w Singapurze? Dokładnie. Byliśmy informowani o 4 releasach rocznie, które były planowane z dwuletnim wyprzedzeniem. Czyli najbliższy, dostępny termin przypadał za 2 lata. Zmian regulacyjnych nie planuje się na za 2-3 lata. Tak więc jeśli w Polsce pojawiała się zmiana regulacyjna, w dużej części były budowane lokalnie. Powstały setki takich rozwiązań klasy EUC, które również musieliśmy zmigrować. Wszystkie trzeba było zmapować oraz przenieść, aby całość nadal działała. To też rodziło problemy, bo zdarzało się że źródła lokalne były sprzeczne z globalnymi. Dla nas najważniejsze było zachowanie ciągłości, aby działały wszystkie karty i produkty. W przypadku kart przepinaliśmy BIN-y w organizacjach płatniczych. Dzięki temu nie trzeba było wysyłać nowych kart. Klienci mogli nieprzerwanie z nich korzystać, zarówno podczas weekendu migracyjnego, jak i po nim. Dotyczyło to kart plastikowych, a także tych stokenizowanych, czy wirtualnych. Pojedyncze, problematyczne przypadki dotyczyły jedynie systemu antyfraudowego. Mógł on zatrzymać lub zablokować transakcję, ponieważ nasze reguły nie były jeszcze w pełni wytrenowane na danych klientów Citi Handlowego. Osobiście analizowałem z zespołem case klienta, który jednego dnia wykonuje transakcję na Cyprze, następnego płynie jachtem do Grecji, a trzeciego jest na spotkaniu w Nowym Jorku. System mógł zareagować na takie „nietypowe” zachowanie i wprowadzić miękką blokadę. W takich przypadkach wysyłamy do klienta SMS z pytaniem, czy to on wykonuje transakcję. Jeśli odpowie twierdząco, transakcja może być kontynuowana; jeśli przecząco blokujemy. Część klientów nie miała jednak telefonu przy sobie albo nie śledziła wiadomości. W efekcie, po upływie określonego czasu, karta mogła zostać zablokowana. To także rodziło kolejne wyzwania. Co dalej? Cały czas monitorujemy ekosystem, transakcje i potrzeby klientów, a niezwłocznie reagujemy. Nadal zdarzają się przypadki, które można nazwać corner case’ami, gdy klientowi trzeba pomóc. Klienci byłego Citi Handlowego w dużej mierze korzystali z bankowości telefonicznej. Mieli doradcę, do którego dzwonili, a on wykonywał dla nich wiele czynności, nawet takie, jak zlecenie przelewu do wysokości 10 mln USD. Dla nas oznaczało to zmianę procesów biznesowych i zwiększenie limitów transakcyjnych nawet o 20 razy. Dla najbardziej zamożnych klientów stworzyliście także nowy typ karty? W ramach migracji, jako pierwsi w Polsce, wspólnie z Mastercard wydaliśmy kartę Mastercard Legend. Oferujemy ją klientom na zaproszenie. Jednocześnie wszystkie usługi przypisane do ich dotychczasowych kart zostały zachowane. Są wśród nich np.: możliwość zamówienia kilka razy w roku limuzyny na lotnisko, dostęp do saloników lotniskowych czy odprawy Fast Track. Chciałbym jeszcze zapytać o Wasze plany. Czy wykorzystanie narzędzi AI jest nadal najważniejszym elementem Waszej strategii? Musimy pamiętać, że AI jest technologią. Potrzebne są dobrze przygotowane use case’y jej wykorzystania, które pozwolą zbudować wartość dodaną i przewagę konkurencyjną. Chcemy przyspieszyć dalsze wdrażanie usług związanych z bankowością konwersacyjną. Mamy już naszą wirtualną asystentkę Velę. Na razie działa ona w sposób reaktywny. Klient zadaje pytanie i otrzymuje odpowiedź. Chcemy, aby potrafiła więcej. Klienci są zabiegani i coraz częściej korzystają z rozwiązań LLM oferowanych przez OpenAI czy Google. Zamiast wyszukiwać informacje tradycyjnie, będą mogli rozmawiać z agentem, który sam je znajduje i prezentuje. Uważam, że w tym kierunku będzie zmierzać bankowość. Rozmowa z wirtualnym asystentem, w wyniku której klient otrzyma gotowy produkt lub usługę bankową do uruchomienia. Po migracji wracamy na szybką ścieżkę rozwoju narzędzi AI. Nawiasem mówiąc, ostatnio przygotowaliśmy i zaktualizowaliśmy politykę AI, przyjmowaną przez zarząd banku i Radę Nadzorczą. Visa i Mastercard mówią o Agentic Payments. To również kierunek dla VeloBanku? Śledzimy ten trend. Pytanie, jak definiujemy Agentic Payments i gdzie dokładnie będzie on wdrażany. Rozumiem to jako sytuację, w której klient ma agenta realizującego płatności na jego polecenie albo zgodnie z wcześniej zdefiniowanymi ustawieniami. Finansowa Vela mogłaby proponować i oferować produkty finansowe, które klient mógłby uruchomić. Jakie są najważniejsze założenia strategii AI przyjętej przez zarząd? Koncentrujemy się na dwóch obszarach. Pierwszy to efektywność i wsparcie pracowników banku zarówno w procesach biznesowych, jak i wytwórczych. Uruchomiliśmy inicjatywę Agentic SDLC, czyli wytwarzanie oprogramowania z wykorzystaniem agentów AI. Drugi obszar to poprawa satysfakcji klienta i dostarczanie usług napędzanych generatywną sztuczną inteligencją. Chodzi o rozwój Veli i inne rozwiązania, które będą pomagały klientom bankować. Jesteśmy także po wdrożeniu pierwszego systemu w banku, który jest w pełni konwersacyjny. Nie ma w nim okienek, tradycyjnego GUI ani przycisków. Jest prompt line. To system dla naszego działu leasingu. W wyniku rozmowy z pracownikiem, sprzedawcą czy dealerem przygotowywana jest oferta. Pierwszy feedback od pracowników i sprzedawców jest naprawdę pozytywny. To nowa jakość i nowy sposób dostarczania usługi bankowej w modelu konwersacyjnym. Czy agenci AI mają wspierać pracowników także poza developmentem? Już ich wspierają. Mamy w banku kilkusetosobową grupę pilotażową, którą wyposażyliśmy w licencje Copilot. Pracownicy są szkoleni z tego, w jaki sposób mogą tworzyć własnych agentów wykonujących określone działania: przygotowujących podsumowanie zadań na dany dzień, przeszukujących ich skrzynkę pocztową czy tworzących wstępną wersję jakiegoś dokumentu. Mamy też zaimplementowane rozwiązania oparte na koncepcji Agentic AI. Sztandarowym przykładem są reklamacje. Kilku agentów analizuje pisma przychodzące do banku. Pierwszy weryfikuje, które pisma są reklamacjami. Kolejny odczytuje reklamację i klasyfikuje ją. Określa, czego dotyczy i który zespół powinien się nią zająć. Trzeci zaś przygotowuje odpowiedź na wysokowolumenowe, powtarzalne reklamacje, np. dotyczące naliczonej opłaty. W tym przypadku sprawdza, klient spełnił wymagane warunki do zwolnienia z opłat w danym miesiącu i przygotowuje odpowiedź. Oczywiście na koniec człowiek weryfikuje odpowiedź. Nic nie jest wysyłane automatycznie. Statystyki są bardzo dobre. Aż 88% odpowiedzi przygotowanych dla reklamacji dotyczących opłat i prowizji nie wymaga korekty przez człowieka i po weryfikacji może zostać wysłane. Kontrolujemy jednocześnie koszty użycia technologii. Firmy BigTech zmieniają znacząco cenniki i modele licencyjne. Przykładowo w GitHub Copilot programiści mieli przydzieloną pulę tokenów na miesiąc za określoną kwotę. Po zmianie modelu licencyjnego kwota ta wystarcza teraz tylko na pierwszych 5 dni! Co zdecydowaliście? Zespół przedstawił mi rekomendację, aby zmienić toolkit i jako alternatywę dla GitHub Copilot zaproponował Claude Code. Ale Anthropic też mocno podnosi ceny. Trzeba stale trzymać rękę na pulsie. Nie chodzi o korzystanie z narzędzia dla jego korzystania, lecz wartość dodaną i opłacalność. Nie możemy dopuścić do sytuacji, w której na koniec dnia technologia jest droższa niż wartość, którą generuje. Zdradzisz, jaki macie budżet na pracownika w dewelopmencie? Ciężko odpowiedzieć wprost na to pytanie. Aktualnie mamy 250 programistów, którzy korzystają z GitHub Copilot. Zakres wykorzystania jest różny, w zależności od języka programowania, czy doświadczenia programisty. Ja grupę użytkowników dzielę na 3 segmenty - Heavy Userów, standardowych i początkujących. A zakres wykorzystania liczymy w tzw. Copilot AI Credits. Heavy userzy to przedział skonsumowanych kredytów powyżej 10 tys., standardowi 1-10 tys., a początkujący poniżej 1 tys. kredytów. W sierpniu programiści skonsumowali ponad 1 mln kredytów. Efekty są obiecujące, w zależności od języka oprogramowania, liczba generowanych przez AI i akceptowanych przez programistę linii kodu przekracza nawet 40%. Faktem jest też, że z dnia na dzień modele są coraz lepsze i procenty te zwiększają się dynamicznie. Równolegle uruchomiliśmy projekt wdrożenia platformy do tworzenia oprogramowania w modelu Agentic SDLC i tutaj oczekiwanym efektem będzie opracowanie gotowego rozwiązania IT przez szereg agentów, bazujących tylko na przekazanych wymaganiach, bez jakiegokolwiek kodowania przez człowieka. Poza rozwojem narzędzi AI jaki jeszcze, duży projekt wrócił na listę priorytetów? Stratega banku na najbliższe lata zakłada skokowy wzrost sprzedaży w obszarze depozytów i kredytów. Prowadzimy kilka projektów, które mają usprawnić procesy i zapewnić realizację tych celów. Są też projekty regulacyjne, które po prostu trzeba wykonać. Dużo dzieje się także w płatnościach. Wchodzą dane ustrukturyzowane. Zmiana ta weszła już w SWIFT. Krajowa Izba Rozliczeniowa planuje zaś na kwiecień 2027 roku przejście na standard ISO XML zamiast plików płaskich. To również duża zmiana, która w mojej opinii będzie wyzwaniem dla całego sektora.
