Od 6 miesięcy do 6 tygodni: przebudowa systemu roszczeń w ubezpieczeniach

Holenderski ubezpieczyciel majątkowy zgłosił się do nas ze znajomym problemem: system przyjmowania roszczeń, który spowalniał likwidatorów, gubił dane między przekazaniami i od trzech lat figurował w planie modernizacji bez żadnego postępu.

Istniejący system był połączeniem 15-letniej aplikacji on-premise, wspólnej skrzynki e-mail pełniącej funkcję kolejki oraz trzech ręcznych kroków przekazania między przyjęciem roszczenia a likwidatorem, który faktycznie je oceniał. Średni czas od przyjęcia do przydzielenia: 4 godziny. Odsetek błędów przy wstępnym wprowadzaniu danych: 12%.

Uzasadnienie biznesowe było jasne. Pytanie brzmiało, jak do tego dojść bez 8-miesięcznego projektu, który wpadłby w okres regulacyjnego zamrożenia.

Dlaczego klasyczne podejście nie miało szans zadziałać

Podręcznikowe podejście do tego typu projektu obejmuje discovery, dokumentację wymagań, wybór dostawcy, projektowanie, budowę, QA, UAT i wdrożenie. Prowadzone sekwencyjnie, z zatwierdzeniem na każdym etapie, zwykle zajmuje to 6–9 miesięcy.

W tym projekcie pojawiły się dwie konkretne blokady.

Po pierwsze, otoczenie regulacyjne. Nowe wymogi raportowania danych o roszczeniach wchodziły w życie w Q3, co oznaczało, że nowy system musiał zostać uruchomiony przed tym terminem, inaczej organizacja musiałaby równolegle prowadzić dwa systemy dla roszczeń już będących w toku.

Po drugie, złożoność integracji. System roszczeń łączył się z sześcioma innymi systemami wewnętrznymi: danymi polis, przetwarzaniem płatności, przechowywaniem dokumentów, logami komunikacji, systemem planowania pracy likwidatorów oraz systemem raportowania regulacyjnego. Każda integracja miała własny kontrakt danych, za który odpowiadał inny zespół wewnętrzny.

6-miesięczny projekt w modelu waterfall z sześcioma punktami integracji i twardym terminem regulacyjnym to nie był plan. To było ryzyko.

Co zrobiliśmy zamiast tego

Zaproponowaliśmy inny zakres. Zamiast wymieniać cały system roszczeń, wymienilibyśmy warstwę przyjmowania: część, w której roszczenia wpływały, były walidowane i kierowane do likwidatorów. To był najbardziej bolesny element obecnego systemu i ten, który miał najbardziej bezpośredni wpływ na produktywność likwidatorów.

Podejście:

Zacząć od 1. dnia z działającym formularzem przyjmowania połączonym z systemem danych polis, bez pełnego zestawu integracji, tylko z jednym połączeniem potrzebnym do walidacji roszczenia
Dodawać jeden punkt integracji tygodniowo, w kolejności wynikającej z wpływu biznesowego
Wdrażać na produkcję w każdy piątek, przepuszczając przez nowy system podzbiór prawdziwych roszczeń
Utrzymywać system legacy równolegle, dopóki nowa warstwa przyjmowania nie przetworzy 1000 roszczeń bez błędu

Harmonogram

Tydzień 1: Działający formularz przyjmowania, połączony z danymi polis. Pierwsze prawdziwe roszczenia przetworzone przez nowy system, pilotaż z udziałem czterech likwidatorów.

Tydzień 2: Integracja przetwarzania płatności. Integracja przechowywania dokumentów. Pilotaż rozszerzony do 20 likwidatorów. Odsetek błędów przy wstępnym wprowadzaniu danych spada z 12% do 2,4%.

Tydzień 3: Integracja logów komunikacji. Zautomatyzowane reguły routingu: roszczenia dopasowywane do likwidatorów według typu ochrony ubezpieczeniowej i obciążenia pracą.

Tydzień 4: Integracja planowania pracy likwidatorów. Dashboard kolejki w czasie rzeczywistym widoczny dla liderów zespołów.

Tydzień 5: Integracja raportowania regulacyjnego. Pełne logowanie zgodności dla każdego zdarzenia w cyklu życia roszczenia.

Tydzień 6: Ruch w systemie legacy dla nowych roszczeń spadł do zera. 1247 roszczeń przetworzonych przez nową warstwę przyjmowania.

Sześć tygodni od rozpoczęcia projektu do pełnego przejścia na produkcję, przed terminem regulacyjnym w Q3.

Rezultat

Mierzalne rezultaty w 6. tygodniu:

Czas od przyjęcia do przydzielenia: z 4 godzin do 22 minut
Odsetek błędów wprowadzania danych: z 12% do 1,8%
Uwolniona wydajność likwidatorów tygodniowo: około 11 godzin (wcześniej poświęcanych na ręczną korektę danych i zarządzanie kolejką)
Wszystkie sześć punktów integracji działających i przetestowanych pod rzeczywistym obciążeniem

Projekt zamknął się na poziomie około 40% budżetu przewidzianego na pełny 6-miesięczny program.

Co to umożliwiło

Zawężony zakres z jasnymi kryteriami sukcesu. Zamiast \"wymienić system roszczeń\" brief brzmiał: \"przetworzyć 1000 roszczeń przez nową warstwę przyjmowania bez błędu przed Q3\". To rezultat, który da się zweryfikować. Wiadomo, kiedy został osiągnięty.

Cotygodniowe wdrożenia na produkcję. Każdego piątku coś działało na żywo, z prawdziwymi użytkownikami i prawdziwymi roszczeniami. To wymuszało wczesne wykrywanie problemów integracyjnych: zamiast znajdować je podczas UAT, znajdowaliśmy je już w 1. tygodniu z udziałem czterech likwidatorów i rozwiązywaliśmy, zanim zdążyły się zamienić w opóźnienia.

Odpowiedzialność jednego zespołu. Jeden zespół trzymał cały cykl od briefu do wdrożonego kodu. Nie było przekazania do QA, osobnego zespołu integracyjnego ani komitetu zatwierdzającego zmiany między programistami a środowiskiem produkcyjnym. Gdy coś się psuło, naprawiali to ci sami ludzie, którzy to zbudowali.

Szacunek 6 miesięcy nie był nierozsądny, biorąc pod uwagę pierwotny zakres. Dostawa w 6 tygodni nie była magią. Była efektem ograniczenia zakresu do tego, co naprawdę wymagało zmiany, ciągłego wdrażania i usunięcia punktów przekazania, w których kumulują się opóźnienia.