Zmiana produktu ubezpieczeniowego: dlaczego trwa miesiącami i co o tym naprawdę decyduje?
Dyrektor sprzedaży obiecuje zarządowi nowy wariant ubezpieczenia motoryzacyjnego na początek kwartału. Tydzień później IT po raz pierwszy słyszy o tym pomyśle i od razu wie, że zmiana nie pójdzie szybko: obejmie pięć systemów, dwa zespoły operacyjne i dokumentację, której nikt nie aktualizował od lat. To, co z perspektywy biznesu wyglądało na prostą modyfikację produktu, zaczyna rozciągać się na kolejne miesiące. W artykule pokazujemy, od czego naprawdę zależy tempo zmian produktowych i jak zaprojektować architekturę, która pozwala wdrażać je sprawniej.
Co warto wiedzieć?
- Zmiana produktu ubezpieczeniowego rzadko wydłuża się z powodu decyzji biznesowej. Najwięcej czasu pochłania przełożenie jej na systemy sprzedażowe, polisowe i szkodowe, zwłaszcza gdy każdy z nich utrzymuje własną definicję produktu, reguły i dane konfiguracyjne.
- Rozdzielenie definicji produktu, reguł biznesowych i przebiegu procesu na niezależne warstwy ogranicza liczbę zależności. Dzięki temu zmiana jednego elementu nie musi automatycznie oznaczać ingerencji w pozostałe części rozwiązania.
- Wersjonowanie pozwala przypisać każdą polisę do zasad obowiązujących w chwili jej zawarcia. Nowa wersja produktu może być stosowana do nowych umów, podczas gdy wcześniejsze polisy pozostają obsługiwane zgodnie z właściwą dla nich wersją warunków, taryf i reguł.
Co sprawia, że zmiana produktu ubezpieczeniowego trwa miesiącami?
Na papierze zmiana produktu ubezpieczeniowego wygląda niewinnie: zaktualizować taryfę, dodać nowy wariant assistance, zmienić zakres ochrony. Kilka decyzji, trochę konfiguracji i gotowe. Tyle że produkt ubezpieczeniowy niemal nigdy nie żyje w jednym systemie. Jego fragmenty są rozsiane między sprzedażą, systemem polisowym, obsługą szkód, taryfikatorem i dokumentami, które muszą zgadzać się z nową wersją warunków.
Jeżeli wszystkie te elementy korzystają z własnych definicji produktu, nawet najmniejszą zmianę trzeba osobno odtworzyć w każdym z tych miejsc. Zespół produktowy ustala nowe zasady, IT przekłada je na kod lub konfigurację, ktoś musi zaktualizować OWU i szablony dokumentów, a testerzy sprawdzają, czy po drodze nic się nie rozjechało. A na koniec i tak pojawiają się pytania: gdzie jeszcze zapisany jest limit, co zobaczy agent, czy szkody obsłużą nowy wariant i czy starsze polisy nadal będą działać według poprzednich reguł?
Im więcej systemów przechowuje własną wersję tej samej informacji, tym dłuższa droga od decyzji do wdrożenia — i tym większe ryzyko, że gdzieś zostanie stara taryfa, limit albo warunek.
W takiej sytuacji presja czasu nie pomaga, tylko szybko obnaża wcześniejsze zaniedbania, nagromadzony dług technologiczny i zależności, o których nikt już nie pamięta. Termin rzucony zarządowi, zanim ktokolwiek sprawdzi realny zakres prac, narzuca tempo, którego obecna architektura produktu zwyczajnie nie jest w stanie utrzymać. W efekcie zespół IT staje się wąskim gardłem, bo musi ręcznie odtworzyć skutki tej samej decyzji w każdym miejscu, w którym zapisano fragment produktu.
Co najczęściej pomijają zespoły, planując zmianę produktu?
Najłatwiejszą, a często także najlepiej opisaną częścią planu jest sam zakres zmiany, dlatego zespoły szybko zaczynają traktować projekt jak listę funkcji do wdrożenia. Znacznie mniej uwagi poświęca się tej mniej wygodnej części: co zmiana oznacza dla produktów, polis i procesów, które już działają i nadal muszą być obsługiwane według wcześniejszych zasad.
Tego etapu nie da się bezpiecznie pominąć ani skopiować z poprzedniego wdrożenia. Rozwiązanie, które sprawdziło się gdzie indziej, w nowym projekcie może rozbić się o inny model danych, integracje albo sposób pracy organizacji. Automatyzacja i modele AI mogą przyspieszyć część analizy czy testów, ale nie zdecydują za zespół, jak nowa wersja produktu ma wejść w obecną architekturę i współistnieć z tym, co już działa.
W rozmowach o zmianach produktowych często pada zdanie: „Nie mamy czasu na analizę. Musimy po prostu wprowadzić zmianę”. Ta presja jest zrozumiała, zwłaszcza gdy termin został już obiecany. Jednak w praktyce pominięcie analizy rzadko skraca projekt. Zwykle tylko przesuwa problemy na później — do testów, wdrożenia albo na produkcję.
Jak zmieniać produkt bez psucia fundamentu, na którym stoi portfel polis?
Kontrolowana zmiana produktu wymaga rozdzielenia trzech obszarów, które w wielu systemach są ze sobą mocno splecione: definicji produktu, reguł biznesowych i przebiegu procesu. Dzięki temu modyfikację można wprowadzić tam, gdzie rzeczywiście jest potrzebna, bez automatycznego otwierania pozostałych części rozwiązania.
Jedna definicja produktu zamiast kilku kopii
Po rozdzieleniu obszarów definicja produktu może być utrzymywana w centralnym konfiguratorze, zamiast być ręcznie odwzorowywana w kolejnych systemach. Na rynku takie rozwiązania bywają nazywane product builderem, product configuratorem albo fabryką produktów. W Altkom Insurance Suite tę funkcję pełni AIS Product Factory, w którym konfiguruje się m.in. warianty, parametry, taryfy i wybrane reguły kalkulacyjne. Dzięki temu systemy sprzedażowe, polisowe i szkodowe mogą korzystać ze spójnego modelu produktu, zamiast przechowywać własne wersje tych samych informacji.
Wersjonowanie bez nadpisywania historii
Samo rozdzielenie obszarów nie wystarczy, jeśli każda kolejna zmiana zastępuje poprzednią. Dlatego potrzebne jest wersjonowanie. Gdy zmieniają się warunki umowy, taryfa albo zasady obsługi, powstaje nowa wersja produktu obowiązująca od określonego momentu. Wcześniejsze polisy pozostają powiązane z zasadami, na których zostały zawarte.
Pozwala to odtworzyć właściwe warunki podczas audytu, reklamacji czy sporu o szkodę, bez stosowania dzisiejszej konfiguracji do umowy podpisanej kilka lat wcześniej.
Proces zarządzany przez orkiestrację
Oddzielenie procesu pozwala zmieniać przebieg sprzedaży lub obsługi bez ingerowania w konstrukcję produktu. Można dodać etap weryfikacji, zmienić kolejność kroków albo przygotować inną ścieżkę dla konkretnego kanału sprzedaży, pozostawiając taryfy, warianty i zasady ochrony bez zmian.
Orkiestracja ma znaczenie zwłaszcza wtedy, gdy organizacja musi szybko odpowiedzieć na nowe wymagania regulacyjne lub operacyjne. Zespół modyfikuje wtedy ten fragment procesu, którego zmiana rzeczywiście dotyczy, zamiast przebudowywać całe rozwiązanie.
Co to podejście zmienia dla poszczególnych ról w organizacji?
Centralne zarządzanie definicją produktu, wersjonowanie i orkiestracja procesu wpływają nie tylko na pracę IT. Dla każdej roli oznaczają coś innego: krótszy czas wdrożenia, mniej pracy ręcznej, lepszą kontrolę nad historią produktu albo bardziej przewidywalny koszt zmiany.
Większa samodzielność biznesu nie oznacza, że IT wypada z procesu. Nadal odpowiada za bezpieczeństwo, integralność danych, integracje i zasady architektoniczne. Zmienia się natomiast to, które modyfikacje można obsłużyć konfiguracyjnie, a które nadal wymagają ingerencji technicznej.
Jak to podejście sprawdza się w praktyce? Na przykładzie nowego ubezpieczyciela motoryzacyjnego
Żeby pokazać, jak centralna konfiguracja, wersjonowanie i orkiestracja działają poza architektonicznym schematem, warto przyjrzeć się jednemu z naszych projektów. Podmiot, który wcześniej pełnił rolę pośrednika, miał przejąć duży portfel polis i niemal od razu rozpocząć samodzielną administrację umowami oraz obsługę szkód. Bez wielomiesięcznego okresu przejściowego i bez przerwy odczuwalnej dla klientów.
System musiał od pierwszego dnia obsługiwać dwa światy jednocześnie: polisy przeniesione z wcześniejszego modelu działania i nowe umowy zawierane już przez ubezpieczyciela. Nie wystarczyło więc uruchomić sprzedaży. Trzeba było zachować historię portfela, odwzorować specyfikę produktów klienta i przygotować rozwiązanie na kolejne zmiany.
Podstawą wdrożenia był standardowy rdzeń Altkom Insurance Suite, rozszerzony o wymagania konkretnej organizacji. W AIS Product Factory utrzymywano definicje produktów, ich warianty, parametry i taryfy, zamiast odtwarzać je osobno w kolejnych częściach systemu. Wersjonowanie pozwalało powiązać polisy z właściwymi dla nich zasadami, a orkiestracja porządkowała przebieg obsługi i umożliwiała zmianę kolejności kroków czy dodanie nowej weryfikacji bez przebudowy całego rozwiązania.
Efektem było uruchomienie działalności z przeniesionym portfelem polis i szkód, sprawniejsza rejestracja zgłoszeń dzięki spójnym danym oraz bardziej przejrzyste rozliczenia z siecią naprawczą. Z perspektywy dalszego rozwoju równie ważny był sam fundament: produkty, ich wersje i procesy nie zostały zaszyte na sztywno pod dzień startu. Dzięki temu kolejne zmiany można wprowadzać bez naruszania zasad przypisanych do polis, które już działają w systemie.1
Czy trzeba wymieniać cały core, żeby szybciej zmieniać produkty?
W tym miejscu pojawia się zwykle kolejne pytanie: czy żeby zyskać taką elastyczność, trzeba wymienić cały system centralny?
Nie zawsze. Pełne wdrożenie nowej platformy core insurance ma sens, gdy ubezpieczyciel chce przebudować większość środowiska, ujednolicić kilka linii biznesowych i uporządkować wspólny model danych oraz procesów. To szeroka transformacja, która daje jeden fundament, ale wymaga objęcia zmianą dużej części organizacji.
Jeżeli głównym ograniczeniem jest sposób definiowania produktu, zarządzania jego wersjami albo prowadzenia procesu sprzedaży i obsługi, nie zawsze trzeba zaczynać od wymiany całego core. Można wdrożyć wybrane elementy rozwiązania, oprzeć je na istniejącym rdzeniu i zintegrować z systemami, które nadal spełniają swoją funkcję. Takie podejście pozwala skupić inwestycję na obszarze, który rzeczywiście blokuje zmianę produktu.
Nie chodzi więc wyłącznie o wybór między „dużym systemem” a „modułową platformą”. Ważniejsze jest to, czy dane podejście pozwala utrzymywać definicję produktu w jednym miejscu, zachowywać jej kolejne wersje i zmieniać przebieg procesu bez przebudowy całego środowiska.
Pełna wymiana core będzie uzasadniona, gdy problem dotyczy całego fundamentu. Podejście modułowe sprawdzi się lepiej, gdy organizacja chce najpierw odblokować konkretną linię produktową, proces albo kanał sprzedaży i rozwijać rozwiązanie etapami.
Podsumowanie
Zespoły rzadko mówią wprost, że najdroższym elementem zmiany produktu bywa strach przed dotknięciem systemu, który akurat działa. Taka obawa potrafi zatrzymać projekt skuteczniej niż brak pomysłu na nowy wariant, podczas gdy konkurencja zdąży już sprawdzić własną ofertę na rynku.
Dobrze przygotowane środowisko daje biznesowi większą kontrolę nad rozwojem portfolio, pozwala realniej planować terminy i sprawia, że pilna zmiana nie uruchamia trybu kryzysowego w całej organizacji. Właśnie tu powstaje przewaga, której trudno nadrobić kolejną funkcją dodaną do systemu.
