Od 6 miesięcy do 6 tygodni: nowy system roszczeń

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 6-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ń z niskim odsetkiem błędów

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 z niskim odsetkiem błędów 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.