W ubezpieczeniach wszystko zaczyna się od polisy. To w niej zapisuje się, co jest objęte ochroną, na jakich warunkach, za ile i do kiedy, a każdy kolejny proces, od likwidacji szkody po rozliczenia, odwołuje się do tego, co system polisowy o niej wie. Dlatego administracja polis to nie moduł obok biznesu, tylko jego fundament, a jakość tego systemu przekłada się wprost na to, jak szybko wprowadzasz nowy produkt i ile kosztuje Cię obsługa portfela.
Z naszego doświadczenia najtrudniejsze nie jest wystawienie pierwszej polisy, tylko zaprojektowanie systemu, który uniesie dziesiątki produktów, lata zmian taryf i wersji warunków bez przepisywania się za każdym razem. Mówmy wprost: to nasza kompetencja. Budujemy oprogramowanie szyte na miarę i pracujemy na platformach takich jak Salesforce czy Creatio, a do projektu ubezpieczeniowego dostarczamy ludzi, którzy taki system zaprojektują i napiszą razem z Twoim zespołem.
Dlaczego administracja polis to rdzeń systemu ubezpieczeniowego?
Bo to jedyne miejsce, w którym żyje pełny, aktualny stan ochrony. Kiedy system polisowy jest sztywny, każdy nowy produkt oznacza miesiące programowania, a każda zmiana taryfy przechodzi przez dział IT zamiast przez dział produktu. Czas wejścia na rynek rośnie, a koszt utrzymania portfela kumuluje się z roku na rok.
Dobrze zbudowana administracja polis odwraca tę zależność. Produkt konfiguruje się zamiast kodować, zmiana warunków nie łamie starych umów, a reszta organizacji dostaje jedno, wiarygodne źródło prawdy o tym, co klient faktycznie kupił. Na tym fundamencie opierają się likwidacja szkód, obsługa klienta, rozliczenia i raportowanie regulacyjne.
Czym jest silnik polisowy i jak projektujemy model danych?
Silnik polisowy to serce systemu: część, która rozumie, czym jest polisa, i pilnuje jej spójności przez cały czas trwania. Projektujemy go wokół trzech filarów:
- model danych polisy - ubezpieczony, przedmiot ochrony, ryzyka, sumy, składka, okresy, powiązania między pozycjami,
- reguły produktowe - co wolno objąć ochroną, jakie są zależności i walidacje, kiedy wariant jest dopuszczalny,
- wersjonowanie - każda zmiana warunków i taryf zapisana w czasie, tak by polisa wystawiona dwa lata temu nadal liczyła się według reguł, które wtedy obowiązywały.
To wersjonowanie jest kluczowe i najczęściej niedoceniane. Bez niego nie da się jednocześnie rozwijać produktu i uczciwie obsługiwać umów zawartych na starych warunkach. Dlatego od pierwszego dnia traktujemy czas jako wymiar modelu danych.
Jak działa konfigurator produktów i taryf (rating tables)?
Celem jest prosty, ale wymagający: nowy produkt lub zmiana taryfy bez zmiany kodu. Budujemy konfigurator, w którym dział produktu definiuje składniki ochrony, warianty, zależności i tabele taryfowe (rating tables), a system sam składa z tego działającą ofertę. Programista jest potrzebny do rozbudowy silnika, nie do każdej korekty stawki.
W praktyce oznacza to oddzielenie logiki produktu od mechaniki aplikacji. Parametry, progi i współczynniki żyją w konfiguracji i tabelach, a nie w instrukcjach warunkowych rozsianych po kodzie. Dzięki temu aktualizacja cennika czy uruchomienie sezonowego wariantu to zadanie biznesu, które wchodzi w dni, a nie w kwartały.
Jak modelujemy cykl życia polisy: od wystawienia po wygaśnięcie?
Polisa nie jest zdjęciem, tylko historią. System polisowy musi obsłużyć pełną ścieżkę, na którą składają się:
- wystawianie - od wniosku i oceny ryzyka po wygenerowanie dokumentu i aktywację ochrony,
- aneksy (endorsements) - zmiany w trakcie trwania umowy, z przeliczeniem składki i zachowaniem pełnej historii,
- wznowienia - automatyczne lub z udziałem agenta, z przeniesieniem danych i zastosowaniem aktualnej taryfy,
- wygaśnięcia, anulowania i storna - z poprawnym rozliczeniem okresu i zwrotów.
Każde z tych zdarzeń zmienia stan polisy i musi zostawić ślad, który da się odtworzyć. Projektujemy ten cykl jako ciąg wersji jednego obiektu, a nie jako osobne tabelki doklejane przy kolejnych potrzebach, bo to właśnie tu najszybciej narasta dług techniczny.
Jak zbudować silnik kalkulacji składki jako API?
Kalkulację składki wydzielamy jako osobną usługę z własnym API, a nie zaszywamy jej w ekranie sprzedaży. Taka decyzja architektoniczna zwraca się wielokrotnie: tę samą logikę wywołuje kalkulator na stronie, aplikacja agenta, proces wznowień i integracja z partnerem, a wynik jest zawsze identyczny.
Silnik przyjmuje dane ryzyka, sięga po właściwą wersję taryfy i zwraca składkę wraz z rozbiciem, które da się pokazać klientowi i skontrolować audytowo. Rozdzielenie kalkulacji od interfejsu pozwala testować reguły cenowe w izolacji i podmieniać taryfy bez ruszania reszty systemu.
Jak rozwiązujemy generowanie i archiwizację dokumentów?
Polisa to także dokument, który klient dostaje, a regulator może skontrolować. Budujemy warstwę, która generuje dokumenty ze spójnych szablonów (polisa, certyfikat, aneks, wezwanie do zapłaty) i wiąże każdy z nich z konkretną wersją polisy, tak aby zawsze dało się odtworzyć, co i kiedy klient otrzymał. Dokumenty trafiają do archiwum z kontrolą dostępu i okresami retencji wynikającymi z przepisów, a cały obieg jest śledzony na potrzeby audytu.
Jak integrujemy system polisowy z core, CRM i otoczeniem?
System administracji polis nie żyje w próżni. Spinamy go z resztą krajobrazu IT, bo polisa karmi danymi niemal każdy inny proces:
- system centralny (core) i finanse - księgowanie składek, rozliczenia, rezerwy,
- CRM (np. Salesforce, Creatio) - widok klienta, obsługa sprzedaży i serwisu,
- likwidacja szkód - która odwołuje się do zakresu i warunków z polisy,
- kanały i partnerzy - portale, aplikacje agentów, porównywarki, integracje API.
Projektujemy te połączenia wokół jasnych kontraktów API i zdarzeń, żeby zmiana w jednym systemie nie wywracała pozostałych. Gdy sercem obsługi klienta jest platforma CRM, osadzamy w niej procesy sprzedaży i serwisu, a logikę polisową trzymamy tam, gdzie jej miejsce, czyli w silniku polisowym.
Jakie kompetencje dostarczamy do projektu policy administration?
Tu wracamy do sedna: nawet bez gotowego wdrożenia w tym obszarze dostarczamy ludzi, którzy taki system zbudują. Dobieramy skład pod konkretny zakres, a nie „na zapas”:
- architekt rozwiązania rozumiejący modelowanie produktów i wersjonowanie,
- programiści backendu budujący silnik polisowy, kalkulację i API,
- specjaliści od platform (Salesforce, Creatio), gdy obsługa opiera się o CRM,
- integratorzy i QA, którzy spinają system z core i pilnują poprawności reguł cenowych.
Opieramy to na realnym doświadczeniu w oprogramowaniu szytym na miarę i w projektach platformowych, a kompetencje weryfikujemy przed startem. Jako partner nearshore z Polski wchodzimy w rytm przeglądów kodu i spotkań bez długiego rozruchu.
Jak robimy to w RITS?
Najczęściej realizujemy to jako projekt dedykowanego oprogramowania prowadzony przez nasz zespół, a tam gdzie trzeba szybko uzupełnić kompetencje, w modelu wzmocnienia zespołu lub zespołu dedykowanego. Zaczynamy od modelu danych i wersjonowania, wydzielamy kalkulację jako API, a produkt oddajemy w ręce biznesu przez konfigurator. Co istotne, nie obiecujemy fikcyjnych wdrożeń: wnosimy kompetencję w custom software i platformach, a dowody rosną razem z projektem. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Od czego zacząć budowę systemu administracji polis?
Zacznij od jednego produktu i pełnego cyklu jego życia, od wniosku po wznowienie, zamiast próbować odwzorować cały portfel naraz. To wymusza właściwy model danych, pokazuje, gdzie naprawdę potrzebujesz konfiguratora, i daje zespołowi działający szkielet, na który dokładacie kolejne produkty. Od razu przesądź też dwie rzeczy: że taryfy żyją w tabelach, a kalkulacja składki jest osobnym API.
Budujesz lub przebudowujesz system administracji polis? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój portfel produktów.