Systémy správy neživotného poistenia (majetok, byty a domy, vozidlá) bývajú staré, rozsiahle a kritické. Každá zmena produktu, sadzby alebo procesu do nich zasahuje a chyba sa prejaví na zmluvách skutočných klientov. Od roku 2023 pracujeme cez partnerskú spoločnosť priamo v projektových tímoch viacerých neživotných poisťovní v Rakúsku a Nemecku: vývoj v Jave, IT a biznis analýza, zmeny v produktových a procesných moduloch, integrácie, testovanie a dokumentácia. Článok je pre architektov, vedúcich projektov a ľudí z compliance, ktorí potrebujú, aby zmeny prichádzali pravidelne a bez prekvapení. Opisuje pravidlá, o ktoré sa v takom prostredí usilujeme, a to, čo z regulácie vyplýva pre dodávateľa vývoja.

Čo je systém správy poistenia a prečo sa nedá vypnúť

Systém správy poistenia (policy administration system) vedie životný cyklus zmluvy: ponuku a výpočet poistného, uzatvorenie, zmeny počas trvania, obnovy, výpovede a storná. Okolo neho stoja ďalšie systémy: výpočet sadzieb, predpis a inkaso poistného, likvidácia poistných udalostí, účtovníctvo, tlač a odosielanie dokumentov, portály pre klientov a sprostredkovateľov, reporting.

Vypnúť ho nemožno z viacerých dôvodov naraz. Sprostredkovatelia a portály uzatvárajú zmluvy aj večer a cez víkend, škody sa hlásia priebežne a mimo pracovného času zvyčajne bežia dávkové spracovania, napríklad obnovy zmlúv, predpis poistného alebo prenosy do účtovníctva. Smernica Solventnosť II (2009/138/ES) navyše v čl. 41 ods. 4 vyžaduje, aby poisťovňa prijala primerané opatrenia na zabezpečenie kontinuity a pravidelnosti svojich činností vrátane plánov pre nepredvídané situácie. Na nasadenie preto slúži dohodnutý časový úsek, ktorý nekoliduje s dávkami ani s obchodnou špičkou.

Zmena má dve polovice a dátum účinnosti

Každá požiadavka má produktovú časť (čo sa poisťuje, za koľko, s akými výlukami a pripoisteniami) a procesnú časť (ako sa zmluva uzatvára, mení a obnovuje a ako sa hlási škoda). Analýza ich oddeľuje, lebo majú iného vlastníka na strane biznisu, iné testy aj iné riziká. Držíme sa pravidla, že zmena bez vlastníka, ktorý ju schváli a prevezme, sa nezačína.

Produktová zmena má takmer vždy dátum účinnosti. Nový tarif sa týka nových zmlúv od určitého dňa, prípadne obnov. Existujúce zmluvy ostávajú na podmienkach, za ktorých vznikli. Pri zmene počas trvania alebo pri likvidácii škody sa musí dať zistiť, aká verzia produktu v danom čase platila. Produktové definície sa preto neprepisujú, ale verzujú. Typická chyba je otestovať nový tarif len na nových zmluvách a zabudnúť na zmenu staršej zmluvy, ktorá ešte beží na predchádzajúcej verzii.

Rytmus vydaní: kalendár, uzávierka, testovacie okno

Rytmus znamená pevný kalendár nasadení, pevný dátum uzávierky zmien pre každé vydanie a pevné okno na integračné a akceptačné testy. Zmena, ktorá nestihne uzávierku, ide do nasledujúceho vydania. Tím aj biznis vopred vedia, kedy čo príde, testeri pracujú so stabilnou verziou a okolité systémy môžu svoje úpravy naplánovať na ten istý dátum. Predvídateľnosť je cennejšia než rýchlosť jednotlivej zmeny, lebo ubúda úprav pridaných narýchlo tesne pred nasadením, ktoré bývajú zdrojom problémov.

Uzávierka však nemôže byť absolútna. Chyba s dosahom na klientov alebo bezpečnostná oprava neznesie čakanie na ďalšie vydanie. Na to slúži samostatná cesta pre núdzové zmeny: menší rozsah, rýchlejšie schválenie a povinnosť zmenu dodatočne zdokumentovať, posúdiť a schváliť. Nie je to obchádzka. Delegované nariadenie (EÚ) 2024/1774, ktoré spresňuje nariadenie o digitálnej prevádzkovej odolnosti (DORA), v čl. 17 výslovne požaduje postupy pre núdzové zmeny aj ich vyhodnotenie po nasadení. Ak sa núdzová cesta bežne používa na zmeny, ktoré len nestihli uzávierku, rytmus sa rozpadá a treba opraviť plánovanie, nie proces.

Rozhrania a dáta: staré a nové chvíľu bežia spolu

Okolité systémy komunikujú s jadrom cez definované rozhrania s verziou. Nekompatibilná zmena rozhrania znamená novú verziu a prechodné obdobie, keď bežia obe. Konzumenti prechádzajú vlastným tempom a stará verzia sa vypína až po dohodnutom termíne a po overení, že ju už nikto nevolá. Kompatibilné rozšírenie, napríklad nové nepovinné pole, novú verziu nepotrebuje, ak ho konzumenti vedia ignorovať. Existujúci kontrakt sa pod bežiacim systémom nemení.

Pre databázu platí rovnaký princíp, známy ako expand/contract alebo parallel change. Najprv sa schéma rozšíri tak, aby fungovala stará aj nová verzia aplikácie (nový stĺpec alebo tabuľka popri starých). Potom sa dáta po dávkach doplnia a aplikácia prejde na novú štruktúru. Staré časti sa odstránia až pri neskoršom nasadení. Vďaka tomu sa dá aplikácia vrátiť o verziu späť bez zásahu do dát. Prepínače funkcií (feature toggles) dovoľujú nasadiť kód vopred a zapnúť ho až k dátumu účinnosti. Majú však cenu: každý prepínač môže zdvojnásobiť počet stavov, ktoré treba overiť, a prepínač, ktorý ostane v kóde po spustení, je technický dlh. Ku každému preto patrí vlastník a termín odstránenia.

Testovanie: referenčné zmluvy a dáta bez skutočných klientov

Jadrom regresného testovania je sada referenčných zmlúv, ktorá pokrýva produkty, verzie tarifov a typické životné situácie zmluvy: uzatvorenie, zmenu počas trvania, obnovu, výpoveď a škodu. Pred zmenou a po nej sa pre ne vypočíta poistné a vygenerujú dokumenty a výsledky sa porovnajú. Rozdiel smie byť len tam, kde ho požiadavka predpokladá. Každý iný rozdiel je nález. Testovacie scenáre sú naviazané na požiadavky, aby sa pri každej položke vydania dalo povedať, čím a s akým výsledkom bola overená.

Najväčší kompromis je pri testovacích dátach. Kópia produkcie je realistická, ale obsahuje osobné údaje klientov. Pseudonymizované údaje sú podľa GDPR (čl. 4 bod 5, odôvodnenie 26) stále osobnými údajmi, ak sa dodatočnou informáciou dajú priradiť ku konkrétnej osobe. Delegované nariadenie (EÚ) 2024/1774 v čl. 16 určuje, že neprodukčné prostredia finančných subjektov majú uchovávať len anonymizované, pseudonymizované alebo randomizované produkčné dáta. Výnimka je možná len pre konkrétne testovanie, na obmedzený čas a so schválením. Osvedčuje sa kombinácia syntetických zmlúv na regresiu a pseudonymizovaného výseku produkcie na akceptačné testy, ktorý je chránený tak, ako zodpovedá osobným údajom.

Návrat: rollback, alebo oprava dopredu

Každý záznam o nasadení obsahuje postup návratu, ktorý je pripravený a podľa možnosti vyskúšaný vopred. Vrátiť kód o verziu späť je jednoduché, ak bola zmena schémy spätne kompatibilná. Ťažšie je to s tým, čo zmena medzičasom urobila: prepočítané poistné, vystavené zmluvy, odoslané dokumenty a predpisy platieb sa nasadením starej verzie nevrátia.

Preto ešte pred vydaním rozhodujeme, kedy dáva zmysel rollback a kedy oprava dopredu (roll-forward): nová malá zmena, ktorá chybu odstráni, a k nej korekcia dotknutých zmlúv. Toto rozhodnutie nemá vznikať až počas nasadenia. Patrí do plánu spolu s kritériom, kedy sa návrat spúšťa (napríklad zlyhanie overovacích testov po nasadení), a s menom človeka, ktorý o ňom rozhoduje.

Čo z regulácie vyplýva pre dodávateľa vývoja

Od 17. januára 2025 sa uplatňuje nariadenie (EÚ) 2022/2554 o digitálnej prevádzkovej odolnosti finančného sektora (DORA). Poisťovne a zaisťovne sú v ňom finančnými subjektmi (čl. 2 ods. 1 písm. n)). Z poisťovní sú vyňaté len malé poisťovne, na ktoré sa podľa čl. 4 nevzťahuje smernica Solventnosť II (čl. 2 ods. 3 písm. b)). Nemecká BaFin s účinnosťou od konca 16. januára 2025 zrušila svoje požiadavky na IT poisťovní (VAIT), aby sa neprekrývali s DORA, a EIOPA k tomu istému dátumu stiahla svoje usmernenia k bezpečnosti a riadeniu IKT. V Rakúsku je príslušným orgánom pre DORA FMA. Popri tom naďalej platí systém správy a riadenia podľa Solventnosti II vrátane písomných politík a pravidiel outsourcingu (čl. 41 a 49).

Pre tím, ktorý dodáva zmeny, z toho vyplývajú najmä tieto očakávania:

  • Zmenové riadenie: zmeny IKT systémov majú byť zaznamenané, otestované, posúdené, schválené, nasadené a overené kontrolovaným spôsobom (čl. 9 ods. 4 písm. e) DORA). Funkcia, ktorá zmenu schvaľuje, má byť nezávislá od tých, ktorí ju požadujú a implementujú, a pre neúspešnú zmenu musia byť určené záložné postupy (čl. 17 nariadenia 2024/1774).
  • Testovanie: rozsah testov zodpovedá kritickosti procesov a aktív. Postup zahŕňa preskúmanie zdrojového kódu so statickým aj dynamickým testovaním a rovnako sa, pokiaľ je to možné, analyzuje a testuje aj softvér tretích strán pred nasadením do produkcie (čl. 16 nariadenia 2024/1774).
  • Incidenty: lehoty na hlásenie závažného incidentu orgánu dohľadu sa rátajú v hodinách. Prvé oznámenie podáva poisťovňa do štyroch hodín od klasifikácie a spravidla najneskôr do 24 hodín od zistenia (čl. 5 ods. 1 delegovaného nariadenia (EÚ) 2025/301). Ak sa ako závažný klasifikuje až po viac než 24 hodinách, lehota je štyri hodiny od tejto klasifikácie (čl. 5 ods. 2). Dodávateľ preto musí vedieť hneď povedať, čo sa kedy nasadilo, kto to schválil a ako sa to dá vrátiť.
  • Zmluvy: zmluvy o IKT službách majú obsahovať povinnosť poskytovateľa pomôcť pri incidente súvisiacom s jeho službou, bezplatne alebo za vopred určenú cenu (čl. 30 ods. 2 písm. f) DORA), a poisťovňa vedie register všetkých takých zmluvných dojednaní (čl. 28 ods. 3). Pri dodávke cez partnerskú spoločnosť je dobré vopred vedieť, ktoré z týchto povinností sa cez zmluvný reťazec týkajú vás.

Kontrolný zoznam pred zaradením zmeny do vydania

  • Zmena má vlastníka na strane biznisu a schválenú špecifikáciu vrátane dátumu účinnosti.
  • Je jasné, ktorých verzií produktu a ktorých zmlúv sa týka: nových, obnovovaných aj bežiacich.
  • Zmena rozhrania je spätne kompatibilná, alebo existuje nová verzia s termínom vypnutia starej.
  • Zmena schémy prešla len fázou rozšírenia a odstránenie starých častí je naplánované do neskoršieho vydania.
  • Regresia na referenčných zmluvách nemá neočakávané rozdiely a výsledky testov sú priradené k požiadavkám.
  • Testovacie dáta neobsahujú nechránené osobné údaje klientov.
  • Záznam o nasadení obsahuje postup návratu, kritérium jeho spustenia a rozhodnutie medzi rollbackom a opravou dopredu.
  • Technická špecifikácia a prevádzková dokumentácia sú aktualizované pred nasadením, nie po ňom.

Žiadne z týchto pravidiel nie je nové a žiadne nevyžaduje hrdinstvo. Ich hodnota je v tom, že sa dodržiavajú pri každom nasadení, aj keď je tlak na termín. Ak zavádzate zmeny do jadrového systému, začnite kalendárom vydaní s jasnou núdzovou cestou, verzovaním produktov a rozhraní a záznamom o nasadení s pripraveným návratom. Tým pokryjete veľkú časť toho, čo DORA pri zmenách vyžaduje, a zostane doplniť záznamy a dôkazy. V regulovanom prostredí je táto nuda to, za čo klient platí.