Jak nahrazujeme 20 let starý core systém pro Slovenská kancelária poisťovateľov

Dvacet let změn v jednom systému

SKP běží na legacy systému, který má za sebou zhruba dvacet let vývoje, úprav, doplňování pravidel a přirozeného technologického dluhu.

Systém stále plní svou úlohu, ale čím dál víc naráží na limity. U každé změny je náročné zjistit, čeho všeho se dotkne. To je v regulované doméně zásadní problém, protože změnu legislativy nebo procesu nelze stavět na odhadech.

Skutečnou výzvou bylo navrhnout doménu nanovo, podle toho, co dnes potřebují SKP i pojišťovny, a přitom nepřijít o know-how uložené ve starém systému, nezastavit provoz a nenechat v auditu šedé zóny. V praxi to znamenalo pět konkrétních úkolů, které popisují následující kapitoly.

Systém, který nejde vypnout

SKP si nemůže dovolit výpadek systému. Nejde o aplikaci, kterou lze vypnout, přepsat a po pár měsících znovu spustit. Vymáhání pohledávek běží průběžně, splátkové kalendáře se táhnou měsíce až roky a upomínky nepočkají, až bude nový systém hotový.

Proto jsme od začátku řešili i to, jak bude nový systém bezpečně koexistovat se stávajícím prostředím. Přechod připravujeme po modulech. Data do nového systému zpětně přelijeme po jednotlivých modulech a integrace řešíme po funkčních oblastech aplikace. Samotné přepnutí do ostrého provozu proběhne najednou při release.

Pravidla, která nebyla nikde zapsaná

Jedním z největších rizik byla roztříštěná znalost původního systému. Některá pravidla byla zapsaná, jiná žila jen v praxi a další se dala pochopit až při podrobném zkoumání konkrétních scénářů.

Nejvíc se to projevilo u integrací. Nový systém se musí napojit na synchronní i asynchronní rozhraní, která vznikala před více než patnácti lety a jejichž chování nebylo nikde zdokumentované. Specifikaci těchto rozhraní jsme skládali zpětně, kombinací reverzního inženýrství a ověřování chování na konkrétních scénářích.

Souběžně jsme si přes workshopy s klientem vytvářeli obraz celé domény. Nestačilo projít stávající obrazovky a sepsat seznam funkcí. Potřebovali jsme pochopit, co se děje při změně regulace, kde vzniká pohledávka, jak se pracuje s rolemi a oprávněními, které kroky musí být auditovatelné a kde jsou největší rizika pro provoz. Výsledkem byla společná mapa domény, díky které šlo rozhodnout, co jde do první vlny, co počká a co je potřeba navrhnout úplně nanovo.

Počítali jsme přitom s tím, že ani důkladná analýza neodhalí vše předem. Část byznys logiky se ukázala až ve chvíli, kdy stály základy systému a pracovalo se s reálnými scénáři.

Přepsání by problém nevyřešilo

Starý systém jsme mohli přepsat do novější technologie. To by ale neřešilo podstatu problému. Proto jsme se s klientem vydali náročnější cestou: redesignem regulované domény na zelené louce.

Ke starému systému jsme přistupovali jako ke zdroji poznání. Byly v něm zachycené roky výjimek, pravidel, rozhodnutí a praktických potřeb. Tam, kde dával odpověď na otázku „proč se to dělá takhle", byl pro nás cenný. Tam, kde jen odrážel historická omezení, jsme hledali lepší řešení.

Stejný přístup jsme uplatnili u rozhraní. Uživatelé v něm tráví celé dny, proto jsme kladli důraz na konzistentnost a jednoduchou orientaci: jednotný design systém napříč všemi moduly, tabulky s filtry tam, kde referenti pracují s velkým množstvím záznamů, a osobní agenda, která každému uživateli ukazuje jeho úkoly, priority a termíny na jednom místě.

Každá akce musí mít stopu

V regulované doméně nestačí vědět, že se něco stalo. Je třeba vědět kdo, kdy, co a v jakém kontextu udělal. U vymáhání pohledávek to platí dvojnásob. Každá upomínka, úhrada či změna splátkového kalendáře musí mít jasnou a dohledatelnou stopu, kterou dokáže zpětně vysvětlit interní tým, právní oddělení i případný audit.

Všechny klíčové události se proto sbíhají v centrálním logu. Každý záznam nese informaci o tom, kdo akci provedl, kdy a v jakém kontextu, ať jde o změnu stavu pohledávky, úpravu limitů nebo export dat. Log lze filtrovat a exportovat, takže podklady pro interní tým, právní oddělení i audit se dají připravit jednoduše, bez asistence vývojářů. Samotný přístup k logu je přitom řízený oprávněními a vyhrazený pro manažerské a administrátorské role.

Součástí systému je i správa delegovaných agend. Když referent zastupuje kolegu, systém eviduje, kdo jednal za koho a v jakém období. To pomáhá při auditu, ale i při každodenním provozu a řešení nejasností.

Jak jsme z velkého celku udělali dodatelný plán

U rozsáhlého enterprise systému se na začátku všechno jeví jako stejně důležité. S takovým zadáním se ale nedá plánovat dodávka.

Rozdělili jsme proto zadání s klientem na oblasti, které šlo analyzovat, navrhnout a vyvíjet samostatně, a domluvili jsme se, co musí obsahovat první vlna. Podmínkou bylo, aby byla použitelná hned po nasazení, bez čekání na doplnění zbytku.

Změnilo to i způsob, jakým klient o projektu uvažuje. Zatímco na začátku patřilo do první fáze všechno, po několika kolech už sám určoval, které funkce jdou hned a které počkají.

Samotná dodávka přitom neběžela klasickým vodopádem. Analýza, design a vývoj probíhaly v těsném závěsu, místy paralelně. Zadání se tak průběžně upřesňovalo, což byla vědomá volba: nová zjištění jsme zapracovávali průběžně, ve fázi, kdy byla jejich změna nejlevnější.

Java, Spring Boot a integrační kontrakty

Nový systém stojí na Javě a Spring Boot, s REST/OpenAPI rozhraními, jasně definovanými integračními kontrakty, promyšleným modelem rolí a oprávnění a s QA procesy a testováním od začátku vývoje.

Podstatné je, že systém zůstává srozumitelný, dá se dál rozvíjet a vzniká jako udržitelný kód, do kterého se vyplatí dlouhodobě investovat. SKP potřebuje jistotu, že za pár let nebude řešit stejný problém jen v modernějším balení.

Co SKP získává

SKP získává systém, který je novým základem pro další rozvoj a začátek modernizace celé organizace. Vymáhání pohledávek, finanční správa závazků, splátkové kalendáře, upomínání, evidence komunikace i úschova dokumentace dostávají jedno přehledné místo místo roztříštěných procesů.

Součástí systému je i osobní agenda každého referenta. Úkoly jako odeslání výzvy k úhradě, příprava žaloby nebo kontrola platby mají přiřazeného vlastníka, termín a prioritu, takže tým vidí stav pohledávek i stav vlastní práce.

Spolu se systémem vznikla živá specifikace klíčových procesů, auditní stopa u citlivých akcí a srozumitelný plán, co patří do první vlny a co bude následovat dál.

MVP bylo dodáno v dohodnutém termínu a projekt pokračuje směrem k plnému nasazení. Nový systém respektuje, jak SKP funguje dnes, a zároveň jí dává prostor měnit procesy a reagovat na regulaci, aniž by se u každé změny muselo znovu zjišťovat, čeho všeho se dotkne.

Co nás projekt naučil

Největší legacy projekty často nebrzdí stará technologie, ale nejasnost: jak procesy fungují, kdo co vlastní, co se stane při změně pravidel a kde se nachází pravda o systému.

U SKP se potvrdilo, že dobrá modernizace začíná schopností pochopit doménu, pojmenovat pravidla a udělat ze složitosti něco, s čím se dá pracovat. Až potom má smysl psát nový kód.