Kompetencje chmurowe są zasobem strategicznym PKO BP

Z Arturem Kurcweilem, wiceprezesem PKO Banku Polskiego nadzorującym Obszar Technologii, rozmawiamy o dostrajaniu i doskonaleniu – realizowanej od roku 2019 – strategii chmurowej Road to Cloud oraz wymiarach organizacyjnych i kulturowych transformacji chmurowej i cyfrowej.

Czym różni się cyfrowa transformacja w PKO BP od Twoich poprzednich doświadczeń zawodowych z tego obszaru?

Biznes i zespoły techniczne PKO Banku Polskiego mają większe doświadczenie w zakresie wykorzystania programów chmurowych, niż wynosi średnia sektora finansowego w naszym kraju. Jest to efekt wczesnego, względem rynku, rozpoczęcia zdecydowanych prac w tym obszarze. Co za tym idzie, wykazywaliśmy się większą odwagą w zakresie testowania różnych wariantów i eksperymentowania w oparciu o już zebrane doświadczenia.

Dziś nasze zespoły okrzepły „chmurowo”. Chętniej, ale też w sposób bardziej systematyczny próbują nowych rzeczy. Stoją za nimi zbudowane przez lata kompetencje technologiczne. Wiedzą, jak wygląda rynek cloud computing, co jest wartością, a jakiego podejścia należy unikać w przypadku złożonych migracji do chmury.

Jak przebiega realizacja strategii Road to Cloud przyjętej jeszcze jesienią 2019 roku?

Jest to duży, rozpędzony, kompleksowy program, dotykający wszystkich obszarów biznesowych i technologicznych banku. Po dwóch latach wykonaliśmy kompletny przegląd inicjatyw związanych z tą strategią. Pozwoliło nam to określić, które jej elementy warto rozwijać, a które należy zmodyfikować tak, aby uzyskać lepszy efekt, i wreszcie, które należy zdjąć z agendy, aby mogły poczekać na swój czas. W moim odczuciu przegląd był bardzo ważnym krokiem dla zespołów zaangażowanych w Road to Cloud. Dowiódł nie tylko, że strategia jest możliwa do zrealizowania, ale przede wszystkim, że potrafimy świadomie kształtować ścieżkę, którą podążamy.

Czy możesz podać przykłady projektów i działań z poszczególnych grup?

Stale rozwijamy wszelkie inicjatywy związane z usługami dla naszych klientów. Wśród nich znajdują się serwisy dostępne z poziomu internetu, aplikacja mobilna czy serwisy transakcyjne. Ponieważ muszą one spełniać warunek łatwej skalowalności, zdecydowaliśmy się na środowisko chmurowe, które oferuje elastyczność i szybki dostęp do tego typu potrzeb. Istnieją sytuacje, w których przewidujemy piki aktywności użytkowników dla wybranej usługi – np. każdego 10. dnia miesiąca.

W razie potrzeby jesteśmy gotowi skalować niezbędne zasoby, jak również możemy optymalizować koszty poprzez ich zmniejszenie w okresie, kiedy nie są one potrzebne. Przykładem takiego rozwiązania jest dodatkowa „nitka” iPKO, która została utworzona u Operatora Chmury Krajowej. Jest ona przeznaczona do ewentualnego wykorzystywania w sytuacjach, w których pojawia się ponadstandardowo wysokie obciążenie kanałów elektronicznych. Przy czym to rozwiązanie należy traktować jako tymczasowe. Pozwala ono uniknąć istotnych wydatków na rzecz infrastruktury technicznej, ze względu na trwający projekt migracji iPKO.

Innym przykładem ilustrującym elastyczność chmury i regułę „pay by use” są środowiska pracy analityków danych – Data Scientists – w chmurze Google. Nasze rozwiązanie automatycznie wygasza tworzone dynamicznie środowiska stosowane do zaawansowanej analityki danych po zakończeniu pracy i pozwala je szybko odtworzyć na początku następnego dnia.

W drugiej grupie działań znalazły się projekty, co do których wiemy, że niezbędna jest skalowalność, ale w tym momencie nie jest ona osiągalna. Wynika to z poziomu trudności wdrożenia podejścia „Lift and Shift” przy dużych inicjatywach. Przykładem tego jest nasz serwis bankowości internetowej iPKO. Teraz, w tym duchu, dzielimy go na mniejsze mikroserwisy i z powodzeniem, stopniowo, przenosimy do chmury.

Dwa lata temu rozpoczął się projekt migracji infrastruktury IT systemu Alnova z infrastruktury komputera mainframe na platformę „przyjazną rozwiązaniom chmurowym”. Na jakim etapie jest ten projekt?

Jak powszechnie wiadomo, platforma mainframe przez ostatnie kilkadziesiąt lat została mocno zoptymalizowana przez producentów dostarczających nowe rozwiązania dla tego środowiska. Pierwotnie prace miały zakończyć się w listopadzie 2022 roku. Część online poszła nam bardzo dobrze, ale konieczność migracji i wdrażania kolejnych batchy na produkcję jest wyzwaniem. Z tego względu musimy zaktualizować harmonogram i zakres niezbędnego zaangażowania banku w ten projekt.

Mówiono wówczas, że „zebrane przez bank doświadczenia pokazują także, że zastosowanie usług chmurowych pozwala osiągnąć wyraźnie lepsze efekty w zakresie wykorzystania zaawansowanej analityki danych oraz uczenia maszynowego do tworzenia oferty dopasowanej do potrzeb i oczekiwań klientów”. Czy moglibyście podzielić się osiągniętymi KPI?

Mogę przedstawić to bardziej obrazowo. Przed wdrożeniem narzędzi zaawansowanej analityki oraz uczenia maszynowego w chmurze, dokonaliśmy dość szczegółowych analiz, z których wnioski nie były dla nas korzystne.

Firmy technologiczne wdrażały zaawansowane modele analityczne wielokrotnie szybciej od nas, co wynikało m.in. z konieczności stosunkowo długiego procesu związanego z zakupem i instalacją niezbędnej infrastruktury oraz braku rozwiązań pozwalających na automatyczne wdrażanie modeli jako usług. To zaś  wymuszało angażowanie zespołów deweloperskich udostępniających model jako usługę.

Obecnie, po wdrożeniu Platformy Machine Learning Ops (MLOps) opartej o rozwiązania chmurowe, określony model może przygotować i udostępnić jako usługę analityk biznesowy, a niezbędna do prac i wdrożenia infrastruktura jest powoływana automatycznie. Dzięki temu zaczęliśmy skracać dystans dzielący nas od wiodących firm technologicznych, szczególnie dla modeli w obszarach Ryzyka i CRM. W tym przypadku jesteśmy już coraz bliżej celu.

Obecnie najwięcej do zrobienia mamy w zakresie przeniesienia na Platformę MLOps wcześniej funkcjonujących w środowiskach bankowych modeli analitycznych.

Czy cel budowy chmury hybrydowej, jako podstawowego środowiska IT, pozostaje aktualny? Jakie rozwiązania, ekosystemy chmury publicznej są obecnie wykorzystywane? A może w ramach Lessons Learned te proporcje się zmieniły? Może szukacie złotej proporcji pomiędzy dostawcami chmury publicznej?

Za każdym wyborem ekosystemu stoi uzasadnienie biznesowe, funkcjonalne lub decyzja strategiczna. Podejmowane przez nas decyzje rozpatrujemy długoterminowo, określając czas zwrotu z inwestycji np. na 3-10 lat. Bierzemy pod uwagę choćby dynamikę rozwoju danej sfery rozwiązań w chmurze, analizując trendy i zachowania naszych klientów. W większości przypadków uzasadnione jest to efektywnością biznesową. Nie szukamy równowagi pomiędzy ekosystemami, ale też nigdy nie budujemy „chmury dla chmury”.

Nie wszystko rozpatrywane jest przez pryzmat konkretnego business case, choć jest to pewna cecha wspólna ery cyfrowej. Gdyby było inaczej, nie powstałby ani Facebook, ani Revolut, ani tysiące startupowych rozwiązań, bez których klienci nie wyobrażają sobie życia. Podobnie patrzymy na to w ramach Lessons Learned strategii Road to Cloud.

Przeanalizowaliśmy 27 aplikacji oryginalnie wpisanych do programu w 2019 roku. Jak wspomniałem, w przypadku połowy dokonaliśmy zmian, rewizji ich harmonogramu, zakresu prac lub całkowicie wstrzymaliśmy ich realizację, a na ich miejsce wprowadziliśmy nowe. Nie oznacza to jednak zmiany jeden do jednego. Przykładowo, za jedną dużą wstrzymaną migrację chmurową, wstawiliśmy do agendy trzy projekty dotyczące mniejszych, ale istotnych dla klientów funkcji.

Ile łącznie przybyło w Road to Cloud nowych inicjatyw i jakich?

Operowanie suchymi liczbami nie oddaje ani złożoności przedsięwzięcia, ani idei samego programu. Nigdy nie zakładaliśmy, że program Road to Cloud będzie miał stały, trudno zmienny zakres. Oczywiście miał ramy, ale od początku zakładaliśmy, że zmieniająca się rzeczywistość, oczekiwania naszych klientów zewnętrznych i wewnętrznych oraz korzyści biznesowe będą determinowały kolejność uruchamiania kolejnych usług w chmurze.

Doskonale się to sprawdziło w okresie pandemii, kiedy od jej początku musieliśmy zabezpieczyć ciągłość działania organizacji, możliwość pracy zdalnej oraz odpowiedniej komunikacji z klientami i wewnątrz organizacji. Usługi chmurowe są podstawą tych rozwiązań. Kolejnym przykładem elastyczności programu jest uruchomienie w chmurze naszego serwisu informacyjnego www.pkobp.pl oraz intranetu. Pierwotnie oba te przedsięwzięcia nie miały dużego priorytetu w całym pakiecie migracyjnym, ale dodatkowe analizy wykazały, że warto przyspieszyć ich realizację i lada dzień oba rozwiązania zostaną uruchomione na bazie usług chmurowych.

Aplikacja mobilna IKO miała być w roku 2021 przeniesiona do Google Cloud, a internetowe iPKO zmigrowane do Microsoft Azure. Jak wygląda symbioza tych środowisk chmurowych?

Migracje obu serwisów są kontynuowane. W ich przypadku podejście „Lift and Shift” nie byłoby ani najlepszą, ani nawet najszybszą formułą. W zamian definiujemy i przenosimy kolejne mikroserwisy.

Tam, gdzie jest to możliwe, sięgamy po gotowe chmurowe usługi i modele AI. Jesteśmy zafascynowani algorytmami sztucznej inteligencji i ich możliwościami. Testujemy je, wprowadzając coraz więcej danych, które pozwalają nam osiągać coraz lepsze wyniki. Dotyczy to analizy ryzyka, analizy typu Next Best Product czy Next Best Step for Customer. Na bazie odkrytych wzorców i testów A/B jesteśmy w stanie szybko modelować i wprowadzać wyniki w życie. Oczywistym następstwem pozytywnej weryfikacji danego modelu w małej skali jest uruchomienie go w oparciu o wielkoskalowalne próby danych.

Bez udziału chmury obliczeniowej nie udałoby się potwierdzić pierwotnych rezultatów ani wypracować dodatkowych wyników, które są możliwe dzięki większej liczbie zmiennych. Mimo że sprawdzanie całościowej hipotezy jest możliwe tylko na podstawie kosztownych modeli wysokoskalowalnego przetwarzania danych, jak dotąd, wszystkie otrzymywane rezultaty są warte swojej ceny.

Jak ta zmiana wpływa na analityków? To osoby mające wiedzę o aparacie matematycznym, często dotąd niewykorzystywaną. Dopiero skalowanie w chmurze daje im szansę rzeczywistego zaprzęgnięcia do pracy swojej wiedzy. Jak ich to zmienia, jak to wpływa na ich pracę, zaangażowanie?

Należy ująć to w ten sposób: niektórzy z naszych pracowników zaczęli odczuwać inny poziom satysfakcji z pracy. Ich zapytania są błyskawicznie weryfikowane, a praca postępuje w szybszym tempie. Kiedyś na wyniki danej analizy musieliby czekać kilka tygodni, teraz wystarczy kilka godzin. To zmienia zarówno efektywność, jak i nastawienie do pracy. Szybsza walidacja pomysłów to jedno, ale algorytmy AI pozwalają wykreować też całe spektrum poszukiwań nowych możliwości badawczych. Jeśli ktoś odczuwa głód odkrywania, to – dostępne dzięki chmurze – rozwiązania Artificial Intelligence potrafią go zaspokoić.

Można więc przypuszczać, że wśród analityków są najwięksi pretorianie chmury.

Jest wielu zwolenników chmury, ale ta konkretna grupa jest zdecydowanie na tak. W tej sytuacji nie muszą nawet wiedzieć, co dzieje się pod udostępnianym im interfejsem analityczno-badawczym. Uzyskują zasoby oraz skalę, choć nie muszą większości ręcznie programować. Dla analityków jest to nowy moduł osadzony w chmurze. Nie muszą już czekać w kolejce na dostępność zasobów technicznych, a tym samym nie muszą też czekać na rezultaty swojej pracy tygodniami czy miesiącami.

Jednym z celów Road to Cloud była budowa wewnętrznych kompetencji chmurowych. Jak ona przebiegała? Czy zaczęliście od uzyskania kompetencji wyższego poziomu, architektonicznych i uniwersalnych, opartych na znajomości mocnych i słabych stron całego rynku chmurowego? A może od kompetencji wertykalnych, specjalistycznych w odniesieniu do poszczególnych chmurowych ekosystemów?

Mamy własne podejście do systematycznej edukacji i szerzenia wiedzy, ale punktem wyjścia są zawsze aspekty, jak podejmowane przez nas inicjatywy można praktycznie wykorzystać z korzyścią dla klienta, produktu oraz lepszego działania danego serwisu. Przykładem tego są serwisy służące budowie analiz ryzyka, takie jak operacje uczenia maszynowego MLOps. Po sformułowaniu naszych oczekiwań przejrzeliśmy dostępne na rynku frameworki i serwisy w chmurach Amazon Web Services, Microsoft Azure i Google Cloud. Postawiliśmy na ostatnią z nich. Efekty okazują się bardzo obiecujące. Dlatego – po tym, jak na małych próbkach sprawdza nam się MLOps – rozwijamy skalę i zastosowania tego typu narzędzi.

Spoglądając przez pryzmat zespołu, stosujemy rozwój wewnętrzny, ale też pozyskujemy świeżą kadrę z rynku. Nieocenioną pracę wykonuje nasze Centrum Doskonalenia Kompetencji. Następnie kreślą scenariusze budowania organicznie wewnętrznie – lub spoza banku – odpowiednich kompetencji. Szczególnie mocno postawiliśmy przy tym na możliwość rozwoju naszych pracowników.

Można zatem powiedzieć, że pod względem kompetencji chmurowych działamy w oparciu o podstawowy zespół, do którego stale dołączamy nowe osoby. Z jednej strony działa więc wielopoziomowy system edukacji i szkoleń – w tym zewnętrznie – z drugiej zaś pozyskujemy kompetencje z rynku, zasilając nowym podejściem zespoły wewnętrzne. Naszą mocną stroną edukacji jest fakt, że jako jedna z kilkunastu firm w Europie możemy korzystać z nielimitowanych szkoleń naszych partnerów Microsoft i Google, co powoduje, że jedynym ograniczeniem jest czas, który pracownik jest w stanie przeznaczyć na edukację rozwiązań chmurowych.

Jednym słowem… hybryda?

Tak. Natomiast w żadnym wypadku nie należy dążyć do wydzielenia tych kompetencji w formie nowej komórki organizacyjnej, która funkcjonowałaby niejako obok naszej firmy. Jestem przekonany, że taka sytuacja nie sprawdziłaby się w organizacji z ponad 100-letnią historią, jaką jest PKO Bank Polski. Ponadto nie uzyskalibyśmy tego, co jest istotą tej zmiany – sprzężenia cyfryzacji z biznesem tak, aby chmurowe możliwości i umiejętności podnosiły jego efektywność szybko i bezpośrednio. Obecny model pozwala nam dynamicznie skalować przedsięwzięcia i projekty, które się sprawdzają, przynosząc wartość.

Czy można mówić o jakiejś proporcji pomiędzy ludźmi, którzy są Cloud Oriented a pozostałymi, którzy pozostają nieco obok tej zmiany i dołączą do niej stopniowo? Budowa takich chmurowych podstaw kompetencyjnych, chmurowej organizacji miała trwać ok. 3 lat…

Pod względem technologii chmurowej jesteśmy spójną organizacją. Z całą odpowiedzialnością mogę powiedzieć, że wszyscy nasi pracownicy IT są Cloud Oriented. W każdym obszarze pionu odpowiedzialnego za aspekty technologiczne znajdują się elementy chmury obliczeniowej. Każdy jest kontrybutorem, motorem wprowadzania rozwiązań chmurowych do banku w mniejszym lub większym zakresie.

Jak to wpływa na resztę banku? Czy w tę zmianę włączony jest również biznes?

Sprzężenie biznesu i IT jest możliwe dzięki strukturze formacji, w której pracujemy. W naszej nomenklaturze jest to odpowiednik Agile Tribe’ów – znanego schematu organizacyjnego metodyki zwinnej. Uważam, że praca w innym modelu nie pozwalałaby na tak szybkie zrozumienie możliwości, jakie stwarza model chmury. Nie byłoby decyzji o doborze Quick Wins, refleksji i uwzględnienia czynnika długu technologicznego, który – przy określonych wyborach – pozostanie do spłacenia. To jest bardzo świadoma decyzja, a przy tym zwinna współpraca.

Wróćmy do transformacji chmurowej. Czy aktualne jest założenie, aby uzyskać docelową proporcję 50/50 systemów kluczowych w chmurze hybrydowej i na własnych zasobach PKO BP? Czy ten wskaźnik jakoś się zmienił? A jeśli tak, to dlaczego?

Tu małe sprostowanie – strategia Road to Cloud nie zakłada żadnego docelowego współczynnika dotyczącego systemów on-premise i w chmurze.  Być może wniosek o docelowym, wspomnianym wcześniej, współczynniku wynika z tego, że jednym z pierwotnych elementów zakresu programu było zagadnienie rezygnacji z własnego zapasowego Data Center i oparcie ciągłości działania na rozwiązaniach chmurowych oraz kolokacyjnych.

Mówiąc o Road to Cloud, zawsze powtarzaliśmy, że o tym, czy kolejne usługi, a co za tym idzie systemy, będą uruchamiane w chmurze, decyduje ogólnie rozumiana analiza korzyści. Oprócz tego mamy dzisiaj do czynienia z zupełnie innym otoczeniem banku, a wybuch wojny w Ukrainie pokazuje mocno, jak bardzo względną kwestią jest dyskusja o „docelowej proporcji”.

Przykładowo – ukraiński PrivatBank na pewnym etapie działań wojennych – jeśli chodzi o kluczowe systemy – chciał być w 100% chmurowy. Jak widać, na określenie apetytu na chmurę duży wpływ ma również bieżąca sytuacja geopolityczna. Niekoniecznie nawet tak dramatyczna, jak ta za naszą wschodnią granicą. Z jednej strony należy mieć wysokie ambicje, ale trzeba również pamiętać o tym, jak zmienne bywa nasze otoczenie. Należy je stale walidować, przeglądać i rozważać.

Stosunek liczby systemów – serwerów, macierzy itd. – funkcjonujących on-premise w stosunku do liczby tych elementów działających w chmurze, nie jest dla mnie wskaźnikiem definiującym progres transformacji chmurowej.

Czy można już porównać „efektywność” infrastruktury własnej i chmurowej? Opisać zalety, kluczowe zastosowania obu, podzielić się doświadczeniami z ostatnich 2-3 lat?

Poziom mierzenia i porównywania efektywności powinien być wspólny dla obydwu modeli. Wszystko zależy od kontekstu oraz czasu, w którym się znajdujemy. Migracja, której obecnie nie bierzemy pod uwagę, za dwa lata może okazać się opłacalną, bo do tego czasu cały ekosystem będzie funkcjonował w chmurze. Przy Lessons Learned, jeśli hamujemy jedną inicjatywę, to wstrzymujemy również te, które są od niej zależne i ściśle z nią powiązane. Nie chcemy „robić chmury dla chmury”. Cały czas kontrolujemy wartość, koszt i termin zwrotu z inwestycji, przy uwzględnianiu całego kontekstu projektowego. Czasami lepiej jest poczekać, co pozwala na skonsolidowanie i dostosowanie pewnych elementów całej układanki, przez co uzyskamy oczekiwaną efektywność biznesową.

Czy jest jakiś termin zakończenia projektu Road to Cloud? Czy w jego przypadku należy mówić raczej o stałej ewolucji? Czy to stale będzie „droga zmiany”?

Patrzę na Road to Cloud jak na kompleksowy program, który składa się z wielu elementów i chociaż mamy plan działania na następne 3 lata, to już wiem, że będzie to długoterminowa droga zmiany. Znajdują się w nim też streamy biorące pod uwagę ogólne potrzeby organizacji, uwzględniając również systemy legacy. Ciągła edukacja jest także elementem tego programu. To działanie obejmuje konkretne zespoły i ma zdefiniowane czynniki sukcesu.

Z drugiej strony, mnóstwo zagadnień dotyczy kultury zwinnej i sposobu myślenia i działania organizacji. Chodzi m.in. o zarządzanie backlogiem, podejście agile czy o myślenie oparte na MVP i przyrostowym budowaniu wartości dla klienta i zespołów. Odpowiednia edukacja może pomóc w zrozumieniu ewentualnych wyzwań, a w połączeniu z praktyką, osiągniemy pełne zrozumienie tych zagadnień. Jest to sfera odpowiedzialna za budowę świadomości formacji Tribe’ów na bazie małych, wciąż przyrastających sukcesów, które sprawiają, że zespół zaczyna wierzyć w działanie, ale także podejmować ryzyko, o co w tradycyjnych projektach nie jest łatwo. Każdy z nich definiowany jest przez trójkąt: koszty-budżet-zakres.

W formacjach zarządzając swoim backlogiem, możemy zrezygnować z części inicjatyw, aby uruchomić inną. Można uznać, że jest to kwestia przyzwolenia na eksperymentowanie i poszukiwanie bardziej obiecujących rezultatów.

Czy w PKO BP działa Laboratorium Innowacji – podobne do tego, realizowanego w Grupie PZU – interfejs do innowacyjnej części rynku, a przy tym wspomagający zarządzanie łańcuchem wartości? Jednym ze znaków rozpoznawczych tamtego programu były poszukiwania aplikacji i adaptacji AI…

Innowacyjność w PKO Banku Polskim, model jej absorpcji, działał dobrze jeszcze przed moim przejściem do banku. Kontynuujemy więc istniejący schemat. Pod wieloma względami jest on podobny do tego, co znałem w PZU, choć jest to inny sektor.

Natomiast z doświadczenia zdobytego w PZU wnoszę obszerne zagadnienie wdrożenia struktury DevSecOps, w które się mocno angażuję. Wierzę głęboko, że jest to wehikuł, który wspiera innowacyjność, eksperymentowanie oraz wszystkie definicje i wartości, o których rozmawiamy, a więc podejście agile, MVP, program Road to Cloud i sposób działania formacji. Ta zmiana organizacyjna i kulturowa jest szalenie ważna, aby wszystkich – Operacje, Development, Cyberbezpieczeństwo i Biznes – angażować w poszukiwanie rozwiązań.

Na jakim etapie jest więc wdrożenie DevSecOps w PKO BP? Czy udało się już rozmyć granice, szczególnie z departamentem bezpieczeństwa?

Istnieją obszary, w których takie podejście sprawdza się bardzo dobrze. Zespoły realizują swoje zadania niezależnie od wiedzy, kto jest deweloperem, a kto odpowiada za utrzymanie. Zaś bezpieczeństwo jest integralną składową takiego systemu działania. W takim układzie wystarczy postawić wspólny cel i nie przeszkadzać. Z drugiej strony, istnieją obszary, gdzie nadal są wyraźne podziały i do ich przezwyciężenia powołujemy wspólne inicjatywy. Może to być np. wdrożenie produktu biznesowego. Nic tak nie motywuje ludzi, jak wspólny cel.  W tym kontekście sprawdzają się formacje, w których nie czeka się na zewnętrzne zatwierdzenie działań. Wszystko dzieje się w ramach jednej grupy, gdzie jest decyzyjność, a bariery są zniwelowane na tyle, na ile się da.

Czy wprowadzenie DevSecOps to także odpowiedź na nadchodzące zmiany w sferze regulacji cyberbezpieczeństwa i w ogóle na zmiany w tym obszarze?

Zdecydowanie tak. Regulatorzy również uczą się DevSecOps, ponieważ jest to model wspierający nowoczesny, szybki i adekwatny do potrzeb biznesu rozwój, ale również wehikuł do mitygacji ryzyk, czym Regulator jest żywo zainteresowany. W naszym przypadku jest to kolejna płaszczyzna bliskiej współpracy z KNF. Chcemy stworzyć skuteczne i efektywne ramy audytowania modelu, który w dalszych etapach prac może zostać szeroko upowszechniony.

Regulator musi mieć wiedzę i narzędzia, które pozwolą mu uzyskać transparentną dokumentację na temat tego kto, kiedy i gdzie odpowiadał za konkretny element procesu czy zmiany produktowe. Zapewnią to narzędzia, w dużej mierze automatyczne i bezstronne, a tym samym audytowalne, a nie organizacyjne struktury, oddzielone fosami i murami departamenty. Pamiętajmy też, że efektywność nie wyklucza bezpieczeństwa, ale żeby to właściwie rozumieć, edukacja i dialog są potrzebne po obu stronach.

Na koniec zapytam o rozporządzenie DORA, które podnosi bezpieczeństwo na wyższy poziom, systematyzuje bowiem zarządzanie odpornością biznesową. Jak do tej zmiany się przygotowujecie? Czy spodziewasz się dużych wyzwań? A może dobrze wkomponuje się to w obecne zmiany?

Dwa miesiące pełnowymiarowej wojny za naszą wschodnią granicą sprawiają, że zagadnienie odporności wymaga zredefiniowania. Katalog zdarzeń, które wydawały się abstrakcyjne i nierealne, uległ zdecydowanemu skróceniu. Zmienia to również sposób myślenia o IT. Tak jak nieco wcześniej pandemia zmieniła podejście do pracy zdalnej, tak teraz wojna zmienia podejście do danych. Jednym dekretem NDU – ukraiński urząd nadzorujący kwestie danych – zniósł zakaz migracji danych bankowych do chmury. To pozwoliło na zapewnienie ciągłości działania.

Rysuje się więc podejście, które można by określić jako konteneryzację modelu biznesowego. Pozwalające – dzięki chmurze – transferować zdigitalizowany model biznesowy z zagrożonych na bezpieczne lokalizacje infrastruktury. Bez przerw lub z minimalnymi przerwami w działaniu…

W najbliższej przyszłości chmura stanie się kluczową technologią i przewagą konkurencyjną zapewniającą ciągłość biznesową i bezpieczeństwo geopolityczne dla wielu firm. W przypadku zniszczenia centrum danych dużego operatora chmurowego, problem transferu całego środowiska IT do innego regionu nie będzie problemem. Pozostaje jedynie kwestia tego, czy i w jakich okolicznościach chcemy z tego skorzystać. Jak oszacujemy ryzyko? Co jesteśmy w stanie zaakceptować przy takiej zmianie? Czy jesteśmy na nią gotowi technologicznie i kompetencyjnie? Zmiana kontynuowana w PKO Banku Polskim pozwala m.in. odpowiedzieć twierdząco na takie strategiczne dylematy.