W niektórych firmach taryfa nie jest zmieniana zbyt często albo zbyt chętnie. Bywa, że wiąże się to z kosztami i stresem, których każdy chciałby uniknąć, za wszelką cenę. Dzieje się tak przez brak odpowiednich narzędzi, a proces na tych dostępnych trwa bardzo długo, generuje koszty i na dodatek jest nieprzewidywalny. Czy może być inaczej?
Właściwie wszystkie towarzystwa ubezpieczeniowe w bardzo podobny sposób kreują swoje taryfy. Wykorzystując matematykę i statystykę, szacują ryzyko i optymalizują funkcję celu, którą najczęściej jest oczywiście rentowność. To podejście nie zmieniło się od lat. To, co się zmienia, to narzędzia wykorzystywane w procesie taryfikacji.
By sprawnie wprowadzać zmiany w taryfach ubezpieczeniowych, jeszcze do niedawna większość towarzystw ubezpieczeniowych decydowała się na zakup narzędzia analitycznego i przeszkolenie swojego zespołu tak, by sprawnie z niego korzystał.
Narzędzia niedoskonałe
Na rynku istnieją narzędzia, które łączą ze sobą zarówno część analityczną, jak i wykonawczą. To oznacza, że po zbudowaniu nowej taryfy możemy jednym kliknięciem ją wdrożyć. Jednak skazani jesteśmy na modele już zaszyte w narzędziu. Dodatkowo, rozwiązania te nie należą do najtańszych, a co najgorsze, miewają problemy z wydajnością obliczeń przygotowanego modelu.
Istnieją również narzędzia pozbawione części wykonawczej, dzięki którym otrzymujemy gotowy model. Później jednak jakoś musimy go „zainstalować” w naszych narzędziach sprzedażowych.
Nie ma właściwie rozwiązań idealnych, które pozwalałyby osiągnąć szybko wszystkie założone cele. Niemal zawsze spotkamy się z jakimś problemem. Zabrzmi niewiarygodnie, ale zdarzyło mi się pracować przy takim systemie, w którym zmiana taryfy powodowała przeliczenie ofert czekających na spolisowanie. By ten temat załatwić, wykonywano różne sztuczki biznesowo-programistyczne, ale za każdym razem proces był na tyle pracochłonny, że okazywało się, iż najlepiej będzie nie zmieniać taryfy zbyt często.
W rękach IT
Najczęściej wdrożenie wymaga, by dział IT dokonał potrzebnej „instalacji” nowej wersji taryfy w systemie sprzedażowym. A z tym bywa różnie. Niestety w swojej karierze kilkakrotnie widziałem, jak ten proces trwał nawet kilka miesięcy (!).
Najpierw zadanie czeka w kolejce do realizacji. Potem, w testach, pojawiają się rozbieżności pomiędzy tym, co przekazał zespół pricingowy, a tym, co zrealizował programista. Na końcu czekamy, aż nasza zmiana trafi we właściwe miejsce w kolejce planowego wydania nowej wersji systemu.
Testy, ach, te testy
Jak możemy zyskać pewność, że programiści wdrożyli zmianę dobrze? Wykonać testy.
Podczas testów odkrywamy błędy, które trzeba poprawić i zacząć w zasadzie testowanie od nowa, co powoduje, że ich przeprowadzenie jest bardzo kosztowne, ale konieczne dla bezpieczeństwa.
Taryfa to newralgiczny element procesu sprzedażowego. Błąd na tym etapie może doprowadzić do obniżenia wyników sprzedaży lub – wręcz przeciwnie – dużych wzrostów sprzedaży nierentownych polis.
Nikt nic nie wie
Kolejny problem nie powstaje od razu, ale nawarstwia się miesiącami lub nawet latami. Zespół pricingu zleca coś działowi IT i widzi rezultaty ich pracy w postaci systemu sprzedażowego, który liczy składkę. Zupełnie nie wie, jak to „w środku” zostało zaimplementowane. Każda kolejna zmiana to zmiana zlecana w ciemno.
Po latach przychodzi moment, gdy ktoś inny przejął modelowanie taryfy, programista zmienił pracę, więc zupełnie inny członek zespołu IT przejął utrzymanie systemu. Od tego momentu komedia pomyłek to w zasadzie tylko kwestia czasu.
Zmiana zlecona w obszarze marki pojazdu nagle dziwnie nakłada się na zmianę za moc pojazdu i dostajemy nieakceptowalnie wysokie składki. Koszty naprawiania tego typu błędów zaczynają się multiplikować i zmiana taryfy zaczyna być stresem, którego wszyscy, za każdą cenę, chcieliby uniknąć.
Kiedy tryb auto to za mało
Z czasem zespoły pricingowe dochodzą do wniosku, że istniejące narzędzia to odpowiednik aparatu fotograficznego z trybem auto. Co prawda możemy zdecydować, czy robimy portret czy panoramę i aparat dostosuje określone parametry, ale nic więcej.
Jak to zwykle bywa, apetyt rośnie w miarę jedzenia. Zespoły zyskują coraz większą wiedzę i okazuje się, że wybrane narzędzie nie pozwala modelować taryfy w satysfakcjonujący sposób, i zaczyna się wymyślanie metod obejścia tego narzędzia.
Nowe podejście
Ostatnio coraz bardziej popularne staje się samodzielne modelowanie taryfy, bez wychodzenia od standardowych modeli zaszytych w narzędziu. Wpływ na to ma z pewnością konkurencja. Wszyscy używają tych samych modeli, mają być może trochę innego klienta idealnego, pod którego dopasowują taryfę, ale obecnie szybki dostęp do informacji pozwala klientowi w mgnieniu oka porównać ofertę kilku towarzystw.
Musimy więc z optymalizacją sięgnąć głębiej, być może użyć większej liczby czynników, a może po prostu wyciągnąć lepsze wnioski z tych danych, które już mamy.
Na sposoby modelowania taryf z pewnością wpływa też stałe przenikanie się dyscyplin naukowych. Jeszcze kilka lat temu podział był prosty – pisaniem kodu zajmowali się programiści, a underwriterzy liczyli swoje „tabelki”.
Współczesny underwriter biegle posługuje się językiem R czy Python, a do pracy zaprzęga dziesiątki publicznie dostępnych bibliotek, pozwalających przy bardzo niskich kosztach przetestować nowy pomysł na stworzenie modelu taryfy.
Nowe podejście – nowe wyzwania
Jak to zwykle bywa, każde nowe podejście niesie ze sobą wyzwania. Przede wszystkim to, w jaki sposób sprawić, by przygotowany model był możliwy do wykorzystania, czyli jak połączyć go z naszym „formularzem sprzedażowym”. Jak sprawdzić, czy ostatecznie klient otrzyma taką składkę, jaką dla niego zaprojektowaliśmy?
Od narzędzia oczekujemy też, aby zmiana realizowana przez inny zespół nie wpływała na naszą konfigurację. Czyli poza testami potrzebujemy także mechanizmu uprawnień, który odseparuje naszą pracę, by taka pomyłka była po prostu niemożliwa.
Potrzebujemy także bezpiecznie przeprowadzić publikację takiej zmiany, dopiero w momencie, kiedy wiemy, że jest ona już dostatecznie przetestowana i działa poprawnie. Narzędzie powinno więc zapewniać, by wszelkie wersje robocze pozostały roboczymi do czasu ich ostatecznej publikacji.
Rozwiązanie (nie)realne
Mając na uwadze wszystkie problemy i wypadki, które mogą zdarzyć się na drodze wdrażania nowej taryfy, odpowiedź na pytanie, czy istnieje system doskonały, może wydawać się prosta. Niewiele jest rozwiązań, które pozwolą nam pokonać bezpiecznie wszystkie wyboje i koleiny.
Chciałbym powiedzieć, że takim rozwiązaniem jest Hyperon. Wierzę, że dziś odpowiada na większość znanych nam bolączek towarzystw związanych z wdrażaniem nowej taryfy, te wymienione w artykule i te, o których nikt głośno mówić nie chce.
Z powodzeniem wdrożyliśmy go już w kilku towarzystwach ubezpieczeniowych. Widzimy, że – w połączeniu z odpowiednim procesem – pozwala aktualizować taryfę tak często, jak to jest potrzebne, aby zrealizować cele postawione przez zarząd, zarówno jeżeli chodzi o wolumen sprzedaży, jak i rentowność.
Co istotne, jak wspominałem wcześniej, wraz z zachodzącymi zmianami pojawiają się nowe wyzwania, a my – choć zabrzmi to jak banał – słuchamy swoich klientów. Widzimy i słyszymy głosy underwriterów, programistów i zespołów IT. Regularnie monitorujemy trendy w branży i dbamy, by Hyperon trafiał celnie w czułe punkty całego procesu kształtowania taryfy. Być może nie jest idealny, ale nie stoi w miejscu i stale się rozwija. Co ciekawe, znajduje coraz to nowe zastosowania.
Hyperon recycle
To interesujące, że wraz z klientami coraz częściej znajdujemy nowe zastosowania dla Hyperona. Regularnie wykorzystywany jest on w wielu firmach już nie tylko do kształtowania taryfy, ale także w innych obszarach biznesu ubezpieczeniowego. Niektórzy z powodzeniem wykorzystują go w procesie segmentacji klientów. Znalazł już swoje zastosowanie także w budowaniu sprzedaży i zaangażowania w sieciach, zarówno własnych, jak i zewnętrznych, poprzez wykorzystanie go do konfiguracji zniżek dla agentów i modelowaniu akcji sprzedażowych. U jednego z klientów odgrywa też ważną rolę w procesie podejmowania zautomatyzowanych decyzji, czy dana kalkulacja powinna przejść przez dodatkowy proces underwritingu.
Myślę, że w czasach poszukiwania optymalizacji nie tylko kosztowych, ale także tych, które pozwalają na poprawę doświadczenia użytkowników, mnogość zastosowań jednego rozwiązania, z tym samym interfejsem, do realizacji wielu celów biznesowych jest jedną z przewag Hyperona. Jak dobrze będzie on wykorzystany – tylko by sprawić, że modelowanie nowej taryfy nawet codziennie będzie proste i przyjemne, czy będzie na przykład segmentował klientów – zależy już tylko od potrzeb i wyobraźni naszych klientów.
Marcin Nowak
Decerto
