Jak zapanować nad origination bez wymiany core? Gdzie kończy się low-code, a zaczyna orkiestracja

Co warto wiedzieć?

• Low-code w procesie origination daje najwięcej wartości tam, gdzie zmiany są częste i przewidywalne: parametry produktów, promocje, formularze, walidacje, słowniki, wymagane załączniki, szablony dokumentów i treści komunikacji.
• Orkiestracja utrzymuje stan sprawy, kolejność kroków, wyjątki i ścieżki manualne. Warstwa integracyjna wymienia dane z systemem core, KYC, OCR, scoringiem i rejestrami. To dwie różne odpowiedzialności, które przy projektowaniu architektury łatwo ze sobą pomylić.
• Modernizacja origination może obejść się bez wymiany systemu core, jeśli orkiestracja, integracje i konfiguracja biznesowa zostaną wydzielone jako osobne warstwy nad istniejącym środowiskiem.

Skąd bierze się presja na low-code w banku i firmie leasingowej?

Wąskie gardło w origination rzadko znajduje się w jednym systemie. Najczęściej powstaje na styku wielu elementów: formularza, dokumentów, KYC, OCR, scoringu, decyzji, podpisu, komunikacji z klientem i systemów core. Wniosek przechodzi przez kolejne aplikacje, ale pełny obraz sprawy często nie jest dostępny w żadnej z nich.

Opóźnienia narastają więc tam, gdzie trudno je szybko zauważyć. Zmiana, która biznesowo oznacza nową pozycję w słowniku, dodatkowy załącznik czy inną treść SMS-a, uruchamia pełną ścieżkę po stronie IT: analizę, development, testy i oczekiwanie na wdrożenie. W tym czasie operacje radzą sobie poza systemem, korzystając z maili, arkuszy i ręcznych przekazań. Klient widzi jedynie „wniosek w trakcie” i kontaktuje się z doradcą lub infolinią, bo nie ma dostępu do bardziej precyzyjnej informacji.

Pod presją są wszyscy. IT mierzy się z backlogiem, właściciel produktu wolniej reaguje na zmiany rynkowe, operacje ręcznie obsługują wyjątki, a compliance z trudem odtwarza, co i kiedy wydarzyło się w konkretnej sprawie.

To właśnie w takim momencie rośnie zainteresowanie low-code. Razem z nim pojawia się jednak obawa, którą często słyszymy w rozmowach z bankami: „nie chcemy kolejnej platformy, którą po wdrożeniu sami będziemy musieli utrzymywać”.

Warto więc zaznaczyć, z jakiej pozycji o tym piszemy. Rozwijamy Altkom Loan Origination, w którym warstwa low-code współpracuje z orkiestracją procesu, integracjami i gotową logiką domenową, a jednocześnie odpowiadamy za osadzenie rozwiązania w środowisku klienta. Nie będziemy więc rozstrzygać, która technologia jest „lepsza”. Pokażemy, gdzie low-code realnie przyspiesza zmianę, za co powinna odpowiadać orkiestracja, jaką rolę pełnią integracje i kiedy nadal potrzebny jest klasyczny development.

Gdzie low-code rzeczywiście przyspiesza pracę zespołu produktowego?

Zacznijmy od tego, że low-code nie musi obsługiwać całego procesu origination, żeby przynosić bankowi wartość. Najlepiej sprawdza się tam, gdzie zmiany są częste, przewidywalne i nie powinny za każdym razem uruchamiać pełnego cyklu developerskiego.

Weźmy sezonową promocję: zmienione parametry oferty, nowy szablon umowy, inna treść SMS-a i dodatkowe pole w formularzu. Żadna z tych zmian nie ingeruje w architekturę, a każda może utknąć w kolejce do analizy, developmentu, testów i release’u. Jeśli zostały wcześniej wydzielone do konfiguracji, właściciel produktu może wprowadzić je znacznie szybciej, a programiści skupić się na integracjach, bezpieczeństwie, modelu danych i bardziej złożonej logice.

Ta elastyczność ma jednak granice. Parametry, formularze czy komunikację warto zmieniać konfiguracyjnie. Stan sprawy, wyjątki i ciągłość procesu wymagają stabilnej logiki procesowej. Kluczowe nie jest więc to, ile można przenieść do low-code, ale gdzie postawić granicę między szybką konfiguracją a elementami, które muszą pozostać pod ścisłą kontrolą techniczną.

Orkiestracja pilnuje, żeby proces nie rozpadał się między systemami

W origination sprawa przechodzi przez KYC, OCR, scoring, systemy core, usługi zewnętrzne i ścieżki manualne. Każdy z tych elementów wykonuje swoją część procesu i zwraca wynik, ale sam nie wie, co powinno wydarzyć się z wnioskiem dalej. Gdy OCR nie odczyta dokumentu, scoring wymaga dodatkowej analizy albo system zewnętrzny nie odpowiada, potrzebna jest warstwa, która zachowa stan sprawy i uruchomi właściwy kolejny krok.

To rola orkiestratora. Prowadzi każdą instancję przez cały proces, pilnuje kolejności zadań, zależności, wyjątków i ścieżek manualnych. Dzięki temu bank wie, gdzie znajduje się sprawa, co ją zatrzymało i kto powinien wykonać kolejne działanie. Konfiguracja skraca drogę do zmiany; orkiestracja pilnuje, żeby zmiana nie zgubiła sprawy po drodze.

Dlaczego samo połączenie z core nie wystarczy, żeby wniosek szedł dalej?

Orkiestrator wie, kiedy proces potrzebuje danych z KYC, OCR, scoringu czy systemu core. Warstwa integracyjna odpowiada za komunikację z tymi systemami: przekazuje i mapuje dane, uwierzytelnia wywołania, obsługuje błędy techniczne i ponowienia.

Integracja może wysłać dane do silnika scoringowego i odebrać wynik, ale nie prowadzi sprawy dalej. To logika procesu określa kolejny krok: automatyczną kontynuację, analizę manualną, oczekiwanie na uzupełnienie danych albo zakończenie danej ścieżki.

Jeśli bank ma sprawne API do core, a mimo to nie potrafi wskazać, gdzie utknął wniosek i co powinno wydarzyć się dalej, problem nie leży już w integracji, tylko w orkiestracji procesu.

Kiedy zmiana nadal wymaga developmentu?

Wszędzie tam, gdzie wychodzi poza przewidziany zakres konfiguracji albo ingeruje w architekturę rozwiązania. Dotyczy to nowych integracji, zmian modelu danych, niestandardowej logiki biznesowej i procesowej, mechanizmów bezpieczeństwa, obsługi nietypowych błędów czy zmian w komunikacji z systemami core.

Takie elementy wymagają analizy wpływu, testów i kontroli technicznej, bo ich konsekwencje wykraczają poza pojedynczy formularz czy parametr produktu. Low-code nie eliminuje więc developmentu z origination, ale pozwala ograniczyć jego udział do tych zmian, które rzeczywiście wymagają pracy inżynierskiej, zamiast angażować programistów do każdej modyfikacji procesu.

Jak podzielić proces origination między warstwy?

Kto odpowiada za zmianę, gdy konfiguracja staje się szybsza?

Techniczna możliwość zmiany parametru nie oznacza, że powinien on być modyfikowany bez kontroli. Próg decyzyjny może dać się zmienić w kilka minut, ale od chwili wejścia zmiany w życie nowa wartość wpływa na każdy kolejny wniosek przechodzący przez scoring.

Dlatego zakres konfiguracji powinien być określony z góry, a odpowiedzialność za poszczególne zmiany jasno podzielona między biznes, IT, Risk i Compliance. Inaczej traktuje się treść komunikatu czy listę wymaganych załączników, a inaczej progi decyzyjne, reguły kierujące sprawę do analizy manualnej, zgody, klauzule czy elementy KYC/AML. W tych obszarach potrzebne są odpowiednie uprawnienia, wersjonowanie i ścieżki akceptacji, ustalone już na etapie wdrożenia.

Prawdziwy test przychodzi później, gdy trzeba odpowiedzieć na konkretne pytania: kto wprowadził zmianę, kiedy zaczęła obowiązywać, kto ją zaakceptował i jaka wersja konfiguracji obsłużyła dany wniosek? Jeśli historia procesu i wersje konfiguracji są zachowane, odpowiedź można odtworzyć z systemu. Bez tego zaczyna się rekonstrukcja z kilku źródeł i pamięci zespołu.

W obszarach objętych RODO, obowiązkami informacyjnymi czy KYC/AML technologia może wspierać kontrolę i audytowalność procesu, ale nie zastępuje zasad governance ani oceny prawnej po stronie organizacji.

Jak ten podział działa w środowisku, w którym stoi już core i kilkanaście systemów?

Low-code, orkiestracja, integracje i development odpowiadają za różne części procesu, więc każda z tych warstw potrzebuje jasno określonej roli. Jak wygląda to w praktyce, pokażemy na przykładzie Altkom Loan Origination, którego hybrydowa architektura opiera się właśnie na takim podziale:

Proces i jego stan

Za orkiestrację odpowiada Camunda, a przebieg procesu jest modelowany w BPMN 2.0. Każdy wniosek stanowi osobną instancję z określonym etapem, stanem i właścicielem zadania. Silnik prowadzi sprawę przez kolejne kroki, zadania użytkowników i systemów, wyjątki oraz ścieżki manualne.

Integracje z otoczeniem banku

Warstwę integracyjną realizujemy w oparciu o Apache Camel. Odpowiada za komunikację z systemami core, rejestrami, OCR, podpisem elektronicznym i innymi usługami zewnętrznymi.

Dla powtarzalnych połączeń SOAP i REST wykorzystujemy gotowe wzorce, a część wywołań REST można parametryzować bez budowania osobnego komponentu od początku. Nietypowe integracje i wyjątki techniczne zostają po stronie developmentu.

Konfiguracja częstych zmian biznesowych

Warstwę low-code tworzą dwa narzędzia konfiguracyjne. Control Center pozwala zarządzać produktami, ofertami, słownikami, załącznikami, szablonami dokumentów i treściami komunikacji. Dynamic Form Builder służy do budowania i modyfikowania formularzy z gotowych kontrolek, bez każdorazowego angażowania developmentu front-endowego.

Zmiany słowników, treści czy parametrów mogą być wprowadzane bez restartu całej aplikacji. Bardziej złożone reguły, wykraczające poza zakres gotowej konfiguracji, realizujemy w Groovy, czyli języku skryptowym pozwalającym zapisać niestandardową logikę biznesową bez budowania osobnego komponentu aplikacji. Takie skrypty pozostają elementem inżynierskim: są wersjonowane i testowane razem z pozostałymi częściami rozwiązania. Zmiana samego przebiegu procesu wymaga natomiast wdrożenia nowej wersji modelu BPMN.

Raportowanie przebiegu procesu

Raportowanie na poziomie instancji i zmiennych procesowych pozwala analizować przebieg spraw, czasy obsługi poszczególnych etapów, poziom automatyzacji oraz miejsca, w których proces najczęściej wymaga interwencji pracownika. Pozwala też wrócić do konkretnej sprawy i odtworzyć jej przebieg, zamiast rekonstruować historię z kilku systemów i ręcznych ustaleń.

Co taki model zmienia po stronie banku?

Hybrydowa architektura ma sens, kiedy nie przenosi problemu z jednego miejsca w drugie. Przy narzędziu do samodzielnej budowy procesu bank może zyskać dużą elastyczność, ale jednocześnie przejąć odpowiedzialność za zaprojektowanie, integrację i późniejszy rozwój całego rozwiązania. Dlatego równie ważne jak możliwości samej platformy jest to, co po wdrożeniu rzeczywiście zostaje po stronie wewnętrznego IT.

W przypadku Altkom Loan Origination ten zakres nie kończy się na dostarczeniu narzędzia. ALO może działać jako warstwa nad istniejącym środowiskiem banku, spinając proces z systemem core, rejestrami, usługami zewnętrznymi i kanałami. Modernizacja nie musi więc zaczynać się od wymiany podstawowych systemów. Można najpierw uporządkować przebieg sprawy, wydzielić warstwę integracyjną i przenieść częste zmiany biznesowe do konfiguracji.

Warunkiem jest możliwość komunikacji z istniejącym core. Jeśli system nie udostępnia potrzebnych interfejsów, konieczne jest zbudowanie warstwy adaptacyjnej, co wpływa na zakres i tempo pierwszego etapu.

Nasza rola nie kończy się na udostępnieniu platformy. Projektujemy proces, osadzamy ALO w środowisku klienta, realizujemy integracje i rozwijamy elementy, które wykraczają poza konfigurację. W jednym z naszych projektów produkcyjnych działa dziś ponad 70 procesów i około 80 integracji REST i SOAP. Przy takiej skali podział odpowiedzialności między konfigurację, proces i integracje przestaje być kwestią architektonicznej elegancji, a zaczyna bezpośrednio wpływać na możliwość utrzymania i rozwijania całego środowiska.

Co ustalić, zanim porównasz oferty dostawców?

Porównanie funkcji to za mało. Dwie platformy mogą oferować podobny zakres low-code, a zostawić bank z zupełnie innym poziomem pracy po starcie. Różnica wychodzi dopiero wtedy, gdy pojawia się pierwsza promocja, nowy wyjątek, zmiana reguły albo kolejna integracja.

Przed wyborem dostawcy warto więc sprawdzić:

• które zmiany zespół produktowy będzie mógł wprowadzić sam,
• które nadal będą wymagały developmentu i release’u,
• kto przejmie utrzymanie modeli procesowych i integracji,
• jak wygląda ścieżka zmian wpływających na decyzję lub compliance,
• co trzeba będzie dobudować po stronie istniejącego core.

To właśnie te odpowiedzi pokażą, czy bank kupuje rozwiązanie gotowe do rozwijania, czy narzędzie, na którym dopiero trzeba będzie takie rozwiązanie zbudować.