System core banking to nie jest kolejna aplikacja w portfelu IT. To centralna księga banku, od której zależą salda rachunków, rozliczenia, naliczanie odsetek i raportowanie do regulatora. Kiedy ten system zwalnia albo się zatrzymuje, nie mówimy o niedogodności, tylko o ryzyku finansowym, reputacyjnym i regulacyjnym. Dla dyrektora IT czy Head of Operations w banku pytanie nie brzmi więc „czy utrzymywać core banking”, lecz „jak utrzymywać go tak, żeby działał przewidywalnie i dał się rozliczyć z poziomu usługi”.
Z naszego doświadczenia przewidywalność nie bierze się z pojedynczych bohaterów gaszących pożary, tylko z powtarzalnego procesu i jasno zdefiniowanych SLA. Dlatego najczęściej wchodzimy do banku w modelu managed services: przejmujemy odpowiedzialność za utrzymanie, monitoring i integracje, a bank rozlicza nas z czasów reakcji i dostępności, a nie z liczby przepracowanych godzin.
Dlaczego utrzymanie i wsparcie core banking jest tak krytyczne?
Bank działa w trybie ciągłym, a jego systemy są ze sobą gęsto powiązane. Każda minuta niedostępności core banking przekłada się na zablokowane przelewy, nieudane płatności kartą i rosnącą kolejkę zgłoszeń na infolinii. Do tego dochodzi presja regulacyjna: nadzorca oczekuje udokumentowanej ciągłości działania, kontroli nad zmianami i pełnej rozliczalności incydentów.
W praktyce krytyczne są trzy rzeczy naraz. Po pierwsze, dostępność systemu w godzinach pracy banku i podczas przetwarzania nocnego. Po drugie, integralność danych, bo błąd w rozliczeniach kosztuje więcej niż chwilowy przestój. Po trzecie, tempo reakcji, gdy coś pójdzie nie tak. Utrzymanie, które adresuje tylko jedną z tych rzeczy, zostawia bank z niekontrolowanym ryzykiem.
Czym jest model managed services i SLA w utrzymaniu systemów bankowych?
Managed services oznacza, że bierzemy na siebie odpowiedzialność za zdefiniowany obszar systemów, a nie tylko użyczamy rąk do pracy. Umawiamy się na efekt opisany w SLA (Service Level Agreement): jak szybko reagujemy, jak szybko rozwiązujemy incydenty i jaką dostępność gwarantujemy.
W utrzymaniu core banking takie SLA zwykle obejmuje:
- poziomy priorytetów (P1-P4) z osobnym czasem reakcji i naprawy dla każdego,
- docelową dostępność usługi (np. w oknach pracy i przetwarzania wsadowego),
- okna serwisowe na zmiany, aktualizacje i prace planowe,
- ścieżkę eskalacji oraz raportowanie zrealizowanych parametrów.
Kluczowa różnica wobec zwykłego wsparcia jest taka, że SLA przenosi rozmowę z „ile osób pracuje” na „jaki wynik dostarczamy”. To właśnie ten wynik bank pokazuje potem audytorowi i nadzorcy.
Jak wygląda monitoring, wsparcie i administracja core banking na co dzień?
Codzienną pracę opieramy na trzech filarach, które muszą działać razem. Monitorujemy system i jego otoczenie, obsługujemy zgłoszenia na kolejnych liniach wsparcia i administrujemy środowiskami, żeby nie dopuścić do sytuacji, w której incydent w ogóle się pojawia.
Na tym poziomie najczęściej:
- obserwujemy wydajność, dostępność i przetwarzanie wsadowe, zanim użytkownik zgłosi problem,
- przejmujemy zgłoszenia na 1., 2. i 3. linii, z jasnym podziałem odpowiedzialności,
- administrujemy środowiskami, uprawnieniami, konfiguracją i zadaniami cyklicznymi,
- analizujemy dane i logi, żeby odróżnić jednorazową usterkę od narastającego trendu.
Chodzi o to, żeby wsparcie nie kończyło się na zamknięciu ticketu, tylko domykało pierwotną przyczynę.
Jak integrujemy core banking z pozostałymi systemami banku?
Core banking rzadko pracuje w próżni. Wokół niego żyją systemy płatnicze, bankowość internetowa i mobilna, hurtownia danych, CRM, moduły raportowania regulacyjnego i usługi zewnętrzne. Utrzymanie oznacza więc także opiekę nad integracjami i warstwą wymiany danych, bo to tam najczęściej pojawiają się ciche błędy.
Dbamy o to, żeby interfejsy i API między systemami były stabilne, a przepływy danych rozliczalne i odtwarzalne. Pilnujemy spójności danych między core banking a hurtownią i raportowaniem, a przy zmianach w jednym systemie sprawdzamy, co dzieje się z resztą. Integracja to w banku nie jest jednorazowy projekt, tylko ciągły obszar utrzymania, który trzeba wersjonować, testować i monitorować jak każdy inny element usługi.
Jak zapewniamy ciągłość działania i bezpieczeństwo?
Ciągłość działania i bezpieczeństwo traktujemy jako część utrzymania, a nie osobny temat „na później”. W praktyce oznacza to pracę na procedurach: planujemy zmiany w oknach serwisowych, utrzymujemy kopie i scenariusze odtworzenia, a dostęp do systemów kontrolujemy zgodnie z zasadą minimalnych uprawnień.
W obszarze bezpieczeństwa i ciągłości zwykle:
- zarządzamy zmianą (change management), żeby żadna modyfikacja nie trafiała na produkcję bez kontroli,
- testujemy odtwarzanie oraz procedury awaryjne, a nie tylko zakładamy, że zadziałają,
- pilnujemy uprawnień i audytu dostępu, bo w banku liczy się rozliczalność każdej operacji,
- dokumentujemy incydenty i zmiany w sposób, który wytrzymuje kontrolę nadzorcy.
Jak mierzymy SLA w utrzymaniu core banking?
SLA działa tylko wtedy, gdy jest mierzalne i widoczne po obu stronach. Rozliczamy się z czasu reakcji i czasu rozwiązania w podziale na priorytety, z dostępności usługi oraz ze skuteczności (ile incydentów rozwiązaliśmy w ramach umówionych progów). Te liczby raportujemy cyklicznie, razem z analizą przyczyn i rekomendacjami, żeby utrzymanie z miesiąca na miesiąc było lepsze, a nie tylko „obsłużone”. Dla dyrektora IT to jest ten zestaw danych, który zamienia utrzymanie w coś, co da się przewidzieć, zaplanować budżetowo i obronić przed audytem.
Jakie kompetencje dostarczamy do utrzymania systemów bankowych?
Skład dobieramy pod konkretne środowisko banku, a nie pod ogólny szablon. W zespołach utrzymaniowych dla bankowości obsadzamy między innymi role administratorów systemów i baz danych, inżynierów wsparcia aplikacyjnego, specjalistów od integracji oraz analityków danych, którzy potrafią czytać to, co dzieje się w systemie. Tam, gdzie bank potrzebuje elastyczności, łączymy managed services z wzmocnieniem zespołu, żeby móc skalować obsadę w górę i w dół zależnie od obciążenia i planów rozwojowych.
Jak robimy to w RITS?
Robimy to na realnym doświadczeniu w sektorze bankowym. Dla grupy wywodzącej się z bankowości spółdzielczej, która urosła do gracza o zasięgu międzynarodowym, od 2017 roku dostarczamy administrację IT, wsparcie techniczne i analizę danych. Z czasem współpraca rozrosła się do blisko 80 specjalistów pracujących w modelu body leasing, co pozwoliło klientowi utrzymywać i rozwijać środowisko bez budowania całego działu od zera.
Co z tego wynika dla innego banku? Że utrzymanie można oprzeć na stabilnym, dedykowanym zespole, który zna środowisko i rośnie razem z organizacją, zamiast reagować dopiero na awarie. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc wchodzimy w rytm pracy, przeglądów i okien serwisowych banku bez długiego rozruchu, a odpowiedzialność rozliczamy przez SLA, a nie przez liczbę przepracowanych godzin.
Od czego zacząć utrzymanie core banking według SLA?
Zacznij od mapy systemów i integracji oraz od pytania, które usługi są naprawdę krytyczne dla pracy banku i dla regulatora. To wyznacza priorytety, poziomy SLA i kompetencje, których potrzebujesz w zespole utrzymaniowym. Jeśli zastanawiasz się, czy postawić na managed services, zespół dedykowany czy wzmocnienie własnych ludzi, różnice opisaliśmy w artykule o modelach współpracy IT.
Chcesz utrzymywać i integrować core banking według twardych SLA? Porozmawiajmy, dobierzemy zespół i model usługi pod Twój bank.