Jak wdrożyć Lean w Banku, gdy System ma 40+ lat?

🎯 Jakiś czas temu współpracowałem z polskim bankiem, który chciał szybkich usprawnień. Problem? Każda próba usprawnień procesu rozbijała się o komputery z 1978 roku, na których nadal działały kluczowe systemy płatnicze. Te komputery nie pozwalały na zmiany w logice procesowej bez przepisania tysięcy linii COBOL-a. To jak naprawiać biuro z papieru w epoce AI. Najpierw trzeba rozkopać system, potem dopiero procesy.

📕 Zainteresowany/a tematem – czytaj dalej… ⬇️

Komputery mainframe i COBOL – dlaczego technologia sprzed 60 lat nadal blokuje zmiany procesowe?

Kiedy analityk Lean próbuje mapować przepływ wartości w polskim banku, często natyka się na dziwny fenomen: procesy, które można byłoby usprawnić w kilka tygodni, wymagają miesięcy prac programistycznych w języku COBOL. Dlaczego?

COBOL (Common Business-Oriented Language) powstał w 1959 roku i do dziś obsługuje około 43% systemów bankowych na świecie. W 2025 roku większość europejskich banków – w tym polskie instytucje finansowe – nadal opiera swoje systemy rozliczeniowe, kredytowe i depozytowe na dużych komputerach uruchamianych w COBOL-u. Według badania GFT, 46% polskich banków wykorzystuje platformy starsze niż 20 lat, a 55% rozpoczęło proces modernizacji dopiero w ostatnich latach.^[i][ii][iii]

Problem nie leży w samym języku, ale w architekturze tych systemów. Komputery mainframe  były projektowane jako monolityczne struktury, gdzie każda zmiana w jednym module wymaga testowania całości aplikacji. W praktyce oznacza to, że usprawnienie procesu – na przykład skrócenie czasu weryfikacji kredytu o jeden krok – może wymagać interwencji w sześciu różnych modułach systemowych, każdy napisany w COBOL-u przez różnych programistów w ciągu ostatnich 40 lat.^[iv]

Dodatkowo, starsze systemy dużych komputerów operują na logice przetwarzania wsadowego, gdzie dane są przetwarzane w określonych przedziałach czasowych (co godzinę, co cztery godziny, raz dziennie), a nie w czasie rzeczywistym. To fundamentalnie uniemożliwia wdrożenie ciągłego przepływu – jednego z filarów Lean Six Sigma – który wymaga przetwarzania transakcji natychmiast po ich wpływie do systemu. Zamiast płynnego procesu, organizacje mają do czynienia z cyklami przetwarzania co godzinę, co cztery godziny, lub nawet raz na dobę – co generuje opóźnienia i marnotrawstwo typu „oczekiwanie”.

Warto zaznaczyć, że problem nie dotyczy wyłącznie Polski. Według Deloitte, 79% firm na świecie wskazuje na pozyskanie talentów obsługujących komputery mainframe jako najważniejsze wyzwanie, a 71% zespołów obsługujących je jest niedoborem kadrowym. To oznacza, że nawet jeśli organizacja chce wprowadzić zmiany, brakuje jej specjalistów, którzy mogliby te zmiany zaimplementować technicznie.^[v]

Ile kosztuje brak elastyczności?

Badania licznych instytucji (MIT Sloan, Forrester, McKinsey) wykazały, że firmy z systemami przestarzałymi tracą średnio 20-30% potencjalnych przychodów z powodu braku możliwości szybkiego wprowadzania nowych produktów na rynek. W sektorze bankowym i ubezpieczeniowym ten wskaźnik jest jeszcze wyższy – zwłaszcza w obliczu konkurencji ze strony startupów fintech (firm technologicznych oferujących usługi finansowe online), które dzięki nowoczesnym architekturom (rozwiązania oparte na chmurze obliczeniowej i mikrousługach) mogą wprowadzać nowe produkty w kilka tygodni zamiast lat.^[vi]

Bazy danych bez porządku – kiedy każdy oddział ma swoją wersję prawdy

Jednym z największych wyzwań w organizacjach z systemami przestarzałymi jest brak jednego wiarygodnego źródła danych. W wielu polskich bankach i firmach ubezpieczeniowych dane klientów są rozproszone w kilkunastu lub kilkudziesięciu różnych bazach danych, z których każda została stworzona dla innego celu, w innym czasie i w innej technologii.

Przykład: Na podstawie badań sektora bankowego, większość dużych polskich banków prowadzi od 5 do 10 różnych systemów do obsługi klientów detalicznych – jeden dla kont osobistych, drugi dla kart kredytowych, trzeci dla kredytów hipotecznych, czwarty dla lokat, i tak dalej. Każdy z tych systemów przechowuje dane klienta w innej strukturze, co oznacza, że proces weryfikacji klienta wymaga odpytania wielu niezależnych baz danych, z których każda może zwracać inne informacje – na przykład różne adresy zamieszkania, różne numery telefonów, różne statusy konta.^[vii]

To prowadzi do marnotrawstwa typu „nadprodukcja” i „defekty” w rozumieniu Lean. Pracownicy muszą ręcznie porównywać dane z różnych źródeł, co generuje błędy i opóźnienia. W jednym z projektów, proces otwarcia rachunku firmowego trwał średnio 14 dni – z czego 9 dni to były oczekiwania na weryfikację danych między systemami.

Dlaczego nie można po prostu zunifikować danych?

Zunifikowanie danych w organizacjach z systemami przestarzałymi to przedsięwzięcie o skali wieloletniej. Problem polega na tym, że każdy system legacy ma swoją własną logikę biznesową zakodowaną bezpośrednio w kodzie aplikacji. Oznacza to, że zmiana struktury danych w jednym systemie może zepsuć dziesiątki procesów w innych systemach, które polegają na konkretnym formacie danych.

Według badania Advapay (2024) oraz raportu Deloitte, koszty integracji i zunifikowania danych w organizacjach finansowych mogą wynieść od 25% do 40% całkowitego budżetu projektu modernizacyjnego. To nie są małe liczby – dla średniego banku w Polsce mówimy o wydatkach rzędu kilkudziesięciu milionów złotych oraz kilku lat pracy zespołów IT.^[viii]

Co więcej, proces zunifikowania danych wiąże się z ryzykiem utraty danych historycznych, które mogą być krytyczne dla audytów regulacyjnych. Instytucje finansowe są zobowiązane do przechowywania pełnej historii transakcji przez 5-10 lat, a w niektórych przypadkach nawet dłużej. Migracja danych z wielu przestarzałych systemów do jednego nowoczesnego systemu wymaga skrupulatnej walidacji, aby nie zgubić ani jednego rekordu – co jest zadaniem niezwykle czasochłonnym.

Integracje systemów – kiedy jedno narzędzie zmienia sześć innych systemów

W organizacjach z systemami przestarzałymi, integracje między systemami stają się jednym z największych źródeł złożoności i kosztów operacyjnych. Banki i firmy ubezpieczeniowe działają na setkach, a czasem tysiącach różnych aplikacji – od systemów księgowych, przez CRM-y, po systemy analityczne i raportowe. Według badań, typowy bank może posiadać od 800 do 1200 różnych przestarzałych systemów, z których każdy komunikuje się z innymi poprzez niestandardowe interfejsy.^[ix]

Problem pojawia się, gdy organizacja chce wdrożyć nowe narzędzie – na przykład system do automatyzacji procesów (BPM), narzędzie analityczne (BI), czy platformę do zarządzania danymi klientów (MDM). Każde takie narzędzie musi zintegrować się z istniejącymi systemami, a to oznacza:

1. Mapowanie struktur danych – co może zająć miesiące, ponieważ każdy przestarzały system ma swoją własną terminologię i strukturę danych.

2. Tworzenie interfejsów API – które często nie istnieją w starych systemach i muszą być budowane od podstaw.

3. Testowanie integracji – które wymaga symulacji tysięcy scenariuszy biznesowych, aby upewnić się, że żadne dane nie zostaną utracone lub zniekształcone.

W rezultacie, wdrożenie jednego nowego narzędzia może wymagać modyfikacji kilkunastu innych systemów, co generuje lawinowy wzrost kosztów i wydłuża czas projektu o miesiące, a nawet lata. Według badania Gartner, 60% budżetu IT w bankach jest wydawane na utrzymanie i integracje istniejących systemów, a nie na innowacje.^[x][xi]

Architektura spaghetti – jak uniknąć chaosu?

W organizacjach, które przez lata dodawały kolejne systemy bez spójnej strategii integracyjnej, powstaje zjawisko określane jako architektura spaghetti – chaotyczna, nieczytelna sieć powiązań między systemami, w której każdy komponent jest połączony z wieloma innymi w sposób przypominający splątane spaghetti. W takiej architekturze zmiana w jednym systemie może spowodować błędy w dziesiątkach innych systemów, co czyni każdą modernizację niezwykle ryzykowną.

Rozwiązaniem jest wdrożenie architektury zorientowanej na usługi (SOA) lub mikrousług, które pozwalają na odseparowanie logiki biznesowej od warstwy integracyjnej. Dzięki temu, każdy system komunikuje się z innymi poprzez standardowe interfejsy API, co ułatwia wymianę systemów i wdrażanie nowych narzędzi.^[xii]

Jednak przejście z architektury spaghetti do architektury mikrousługowej to wieloletni proces, który wymaga nie tylko inwestycji finansowych, ale również zmiany kultury organizacyjnej i współpracy między działami IT a biznesem. Według badania z 2025 roku, tylko 20% organizacji z sektora finansowego w Europie Środkowo-Wschodniej zrealizowało pełną transformację do architektury mikrousługowej, podczas gdy 55% znajduje się w fazie pilotażowej lub planowania.^[xiii]

Compliance i historia danych – dlaczego nie możesz wyłączyć tego, co może być audytowane?

Jednym z najważniejszych powodów, dla których instytucje finansowe nie mogą po prostu „wyłączyć” starych systemów i przejść na nowe, jest wymóg regulacyjny dotyczący przechowywania pełnej historii danych i możliwości ich audytu. Banki i firmy ubezpieczeniowe są zobowiązane do zachowania kompletnych zapisów transakcji przez wiele lat. Może to być nawet od 5 do 30 lat.^[xiv]

Co więcej, przestarzałe systemy często przechowują dane w formatach, które nie są kompatybilne z nowoczesnymi standardami – na przykład w strukturach danych specyficznych dla dużych komputerów, takich jak VSAM (Virtual Storage Access Method) czy IMS DB (Information Management System Database). Migracja tych danych do nowoczesnych baz danych SQL lub NoSQL wymaga konwersji formatów, co jest procesem podatnym na błędy i wymaga wielokrotnej walidacji.

Dodatkowo, wiele organizacji finansowych musi spełniać wymogi różnych regulatorów w różnych krajach – na przykład RODO w Unii Europejskiej, KNF w Polsce, FCA w Wielkiej Brytanii, czy FINMA w Szwajcarii. Każdy z tych regulatorów może mieć inne wymagania dotyczące przechowywania i audytu danych, co dodatkowo komplikuje proces modernizacji.

Strategia „równoległy system” – jak migrować bez utraty danych?

Jedną z najczęściej stosowanych strategii w modernizacji systemów bankowych jest „równoległy system” – równoległe uruchomienie starego i nowego systemu przez określony czas (zazwyczaj od 6 do 18 miesięcy, średnio ~12 miesięcy). W tym czasie, wszystkie transakcje są przetwarzane przez oba systemy, a wyniki są porównywane, aby upewnić się, że nowy system działa identycznie jak stary.^[xv]

Takie podejście minimalizuje ryzyko utraty danych i pozwala na stopniowe przejście bez przerwy w działaniu biznesowym. Jednak wiąże się to z dodatkowymi kosztami – organizacja musi utrzymywać dwa systemy jednocześnie, co podwaja koszty operacyjne i wymaga dodatkowych zasobów ludzkich do zarządzania procesem migracji.

Według praktyki przemysłowej (badania Deloitte i Gartner), średni czas trwania równoległego systemu w projektach modernizacji core banking wynosi od 6 do 18 miesięcy, a koszty mogą wzrosnąć o 20-30% w porównaniu do pierwotnych szacunków. Niemniej jednak, większość ekspertów zgadza się, że równoległy system jest konieczny w przypadku krytycznych systemów bankowych, aby zminimalizować ryzyko awarii i utraty danych.^[xvi]

Brak jedynego wiarygodnego źródła danych – kiedy dane w systemie A nie zgadzają się z danymi w systemie B

Jak już wspomniałem wcześniej, jednym z kluczowych problemów w organizacjach z systemami przestarzałymi jest brak jednego wiarygodnego źródła danych. W praktyce oznacza to, że różne systemy przechowują różne wersje tych samych danych – na przykład system A może wskazywać, że klient ma adres zamieszkania w Warszawie, podczas gdy system B wskazuje na adres w Krakowie.

To prowadzi do marnotrawstwa typu „ponowne przetwarzanie” i „defekty” w rozumieniu Lean. Pracownicy muszą ręcznie uzgadniać dane z różnych systemów, co jest czasochłonne i podatne na błędy. W jednym z projektów, który analizowałem, 30% czasu pracy zespołu obsługi klienta było poświęcone na weryfikację i korygowanie rozbieżności w danych klientów.

Zarządzanie danymi podstawowymi (MDM) – rozwiązanie czy nowy problem?

Jednym z rozwiązań na problem braku jedynego wiarygodnego źródła danych jest wdrożenie systemu zarządzania danymi podstawowymi (MDM) – centralnej platformy, która zbiera dane z różnych systemów i tworzy jedną, spójną bazę danych, będącą jedynym wiarygodnym źródłem informacji dla całej organizacji. MDM pozwala na automatyczną synchronizację danych między systemami oraz wykrywanie i rozwiązywanie konfliktów w danych.^[xvii]

Jednak wdrożenie MDM w organizacji z systemami przestarzałymi to złożone przedsięwzięcie, które może zająć od 2 do 5 lat i kosztować miliony złotych. Co więcej, MDM wymaga ciągłego zarządzania i utrzymania, ponieważ dane w różnych systemach ciągle się zmieniają, a MDM musi być na bieżąco aktualizowany.

Według badania z 2025 roku, tylko 35% organizacji finansowych w Europie wdrożyło pełnoprawny system MDM, podczas gdy 40% znajduje się w fazie planowania lub pilotażu. Główne przeszkody to wysokie koszty, brak zasobów ludzkich oraz trudności w integracji z istniejącymi przestarzałymi systemami.^[xviii]

Koszty konwersji – ile będzie trwać przejście bez shutdownu usługi?

Jednym z najważniejszych pytań, które organizacje zadają sobie przed rozpoczęciem modernizacji, jest: ile to wszystko będzie kosztować i ile czasu zajmie? Odpowiedź nie jest prosta, ponieważ koszty i czas trwania zależą od wielu czynników – skali organizacji, złożoności przestarzałych systemów, dostępności talentów, oraz poziomu ryzyka, które organizacja jest gotowa zaakceptować.

Według badania Advapay (2024), całkowite koszty migracji core banking system mogą obejmować:^[xix]

1. Koszty oprogramowania – zakup licencji na nowy system, koszty konfiguracji i customizacji.

2. Koszty integracji – połączenie nowego systemu z istniejącymi systemami przestarzałymi.

3. Koszty migracji danych – konwersja danych z formatów legacy do nowych formatów.

4. Koszty szkoleń – przygotowanie pracowników do pracy z nowym systemem.

5. Koszty równoległego systemu – utrzymanie dwóch systemów jednocześnie przez okres przejściowy.

6. Koszty wsparcia zewnętrznego – zatrudnienie konsultantów, integratorów i dostawców technologii.

W sumie, koszty modernizacji core banking system mogą wynieść od kilkudziesięciu do kilkuset milionów złotych, w zależności od wielkości banku i zakresu projektu. Czas trwania projektu może się wahać od 2 do 7 lat.^[xx]

Jak obniżyć koszty i skrócić czas wdrożenia?

Jednym ze sposobów na obniżenie kosztów i skrócenie czasu wdrożenia jest zastosowanie strategii stopniowej modernizacji, w której organizacja stopniowo wymienia poszczególne moduły przestarzałego systemu, zamiast próbować wymienić wszystko naraz. Takie podejście pozwala na:^[xxi]

1. Minimalizację ryzyka – jeśli coś pójdzie nie tak w jednej fazie, nie wpływa to na cały system.

2. Szybsze osiągnięcie wartości biznesowej – organizacja może zacząć czerpać korzyści z modernizacji już po pierwszej fazie, zamiast czekać na zakończenie całego projektu.

3. Lepsze zarządzanie budżetem – koszty są rozłożone w czasie, co ułatwia planowanie finansowe.

Innym podejściem jest strategia stopniowej wymiany (znana w branży IT jako „strangler pattern”), w której nowe funkcjonalności są implementowane jako osobne, niezależne komponenty (mikrousługi), które sukcesywnie przejmują zadania od starego systemu. Dzięki temu system przestarzały pozostaje w działaniu, ale jego rola jest stopniowo zmniejszana, aż w końcu można go całkowicie wyłączyć bez ryzyka utraty danych. Ta strategia jest szczególnie popularna w organizacjach, które chcą uniknąć ryzykownej migracji „na jeden raz” i związanego z nią ryzyka.^[xxii]

Talenty – gdzie znaleźć osoby do COBOL + Lean?

Jednym z największych wyzwań w modernizacji przestarzałych systemów jest brak wykwalifikowanych specjalistów. Jak już wspomniałem, 79% firm wskazuje na pozyskanie talentów obsługujących komputery mainframe jako najważniejsze wyzwanie, a 71% zespołów obsługujących je jest niedoborem kadrowym.^[xxiii]

Problem polega na tym, że COBOL nie jest już nauczany na większości uczelni, a młode pokolenie programistów woli uczyć się nowoczesnych języków, takich jak Python, JavaScript, czy Java. W rezultacie, większość programistów COBOL to osoby w wieku 50-60 lat, które wkrótce przejdą na emeryturę.^[xxiv]

Dodatkowo, organizacje potrzebują nie tylko programistów COBOL, ale również specjalistów Lean Six Sigma, którzy rozumieją, jak optymalizować procesy biznesowe. Połączenie wiedzy technicznej (COBOL, komputery mainframe) z wiedzą procesową (Lean, Six Sigma) jest niezwykle rzadkie i wysoko cenione na rynku pracy.

Jak organizacje radzą sobie z brakiem talentów?

Organizacje stosują kilka strategii, aby poradzić sobie z brakiem talentów:

1. Programy szkoleniowe – niektóre banki, takie jak SEB w Szwecji, prowadzą wewnętrzne bootcampy COBOL, w których uczą młodych programistów podstaw systemów wielkoskalowych i COBOL-a. Podobne programy powstają w Kyndryl, które co roku przyjmuje 100 młodych specjalistów do swoich zespołów obsługujących komputery mainframe.^[xxv]

2. Partnerstwa z uniwersytetami – niektóre organizacje współpracują z uczelniami, aby przywrócić nauczanie COBOL-a do programów studiów informatycznych. Na przykład, kilka uniwersytetów w Wielkiej Brytanii ponownie włączyło COBOL do swoich programów nauczania, uznając, że jest to ważna umiejętność dla branży finansowej.^[xxvi]

3. Outsourcing i offshoring – wiele organizacji zleca projekty modernizacyjne firmom zewnętrznym, które specjalizują się w systemach przestarzałych, takim jak IBA Group, GFT, czy TCS. Te firmy mają dostęp do większych pul talentów i mogą realizować projekty w modelu offshore (na przykład w Polsce, Indiach czy Brazylii).

4. Wykorzystanie AI i automatyzacji – nowe narzędzia oparte na sztucznej inteligencji, takie jak IBM Watson czy AWS CodeGuru, mogą automatycznie analizować kod COBOL i sugerować usprawnienia, co zmniejsza zapotrzebowanie na ręczną pracę programistów. Według badania z 2025 roku, AI może osiągnąć 93% dokładności w automatycznej modernizacji kodu COBOL do Java, co przewyższa 75% dokładności ręcznej pracy i 82% dokładności narzędzi opartych na regułach.^{[xxvii][xxviii]}

Podsumowanie

Modernizacja przestarzałych systemów w bankach i firmach ubezpieczeniowych to jedno z największych wyzwań, przed którymi stoi dziś sektor finansowy. Systemy komputerów minframe i COBOL, które powstały kilkadziesiąt lat temu, nadal obsługują kluczowe procesy biznesowe, ale jednocześnie blokują możliwość wprowadzania usprawnień Lean Six Sigma i utrudniają transformację cyfrową.

Jeśli jesteś liderem zespołu Lean lub menedżerem operacyjnym w banku czy firmie ubezpieczeniowej, zacznij od mapy zależności systemów – zrozumienie, które systemy są ze sobą połączone i jakie procesy biznesowe obsługują, to pierwszy krok do skutecznej modernizacji. Rozważ stopniową modernizację zamiast próby wymiany wszystkiego naraz – to zmniejszy ryzyko i pozwoli na szybsze osiągnięcie wartości biznesowej. Wprowadź równoległy system, aby zminimalizować ryzyko utraty danych i zapewnić ciągłość operacyjną podczas przejścia.

Jeśli pracujesz w HR lub zarządzasz talentami, zastanów się nad wewnętrznymi programami szkoleniowymi, które łączą wiedzę techniczną (COBOL, systemy wielkoskalowe) z wiedzą procesową (Lean, Six Sigma). Takie programy mogą być kluczem do zatrzymania wiedzy w organizacji i przygotowania zespołów na przyszłe wyzwania.

I wreszcie, przeprowadź analizę cost-benefit modernizacji – nie każdy system przestarzały musi być od razu wymieniony. Czasami inwestycja w integracje i nowe warstwy API może być bardziej opłacalna niż pełna wymiana systemu. Kluczem jest znalezienie równowagi między kosztami utrzymania a korzyściami z modernizacji.

🤔 Czy Twoja organizacja wie, które przestarzałe systemy są największą przeszkodą w transformacji Lean? Podziel się w komentarzach swoimi doświadczeniami – chętnie poznam Twoje historie i wyzwania! ✍️

🎁 Wygraj 1 z 21 nagród! – WEŹ UDZIAŁ W KONKURSIE 🛑