Kiedy towarzystwo ubezpieczeniowe planuje duży projekt IT – nowy system polisowy, przebudowę procesu szkodowego, wdrożenie silnika oceny ryzyka, dostosowanie nadzoru nad siecią sprzedaży do nowych wymogów regulacyjnych – zwykle ma już wstępną listę wymagań, budżet i termin rozpoczęcia projektu. Brakuje jednak odpowiedzi na trzy pytania: czy ta lista wymagań faktycznie tworzy spójną koncepcję rozwiązania, czy da się ją zbudować w zakładanym środowisku oraz czy realizacja projektu przy przyjętych założeniach jest uzasadniona biznesowo?
Discovery odpowiada na te pytania, zanim powstanie pierwsza linia kodu – nie dopiero w trakcie budowy systemu, gdy każda zmiana kosztuje już wielokrotnie więcej.
Faza Discovery – na czym polega?
Discovery to zamknięty w czasie etap poprzedzający development. Prowadzimy go wspólnie z zespołem klienta, najczęściej w modelu Time & Material. Efektem nie jest jedynie raport z rekomendacjami, lecz konkretny pakiet materiałów: koncepcja rozwiązania, specyfikacja biznesowa i techniczna, backlog, makiety, proof of concept dla elementów obarczonych największym ryzykiem oraz wycena oparta na zweryfikowanym zakresie.
Pracujemy równolegle w trzech obszarach: zarządczym, analitycznym i technicznym. Dzięki temu już na starcie wychwytujemy niespójności między celami biznesowymi, wymaganiami i założeniami technicznymi. Bez takiej analizy często ujawniają się dopiero podczas wdrożenia – kiedy ich usunięcie jest znacznie droższe.
Trzy obszary Discovery w praktyce
Przyjrzyjmy się temu na konkretnym przykładzie. Do 1 lipca 2027 roku każdy zakład ubezpieczeń współpracujący z siecią agencyjną musi dostosować nadzór nad agentami i osobami fizycznymi wykonującymi czynności agencyjne (OFWCA) do Rekomendacji KNF dotyczących dystrybucji ubezpieczeń. W rozmowach o realizacji tego celu szybko pojawia się pozornie oczywiste rozwiązanie: portal dla agentów i OFWCA służący do gromadzenia informacji o szkoleniach, danych wymaganych w rejestrze agentów oraz oświadczeń.
- Obszar zarządczy zaczyna się od ustalenia, kto w zakładzie odpowiada za nadzór nad siecią. Formalnie odpowiedzialność spoczywa na zarządzie, jednak w praktyce informacje o agentach są rozproszone między sprzedażą, compliance i administracją sieci. Rekomendacje wymagają, aby zakład oceniał sposób wykonywania czynności agencyjnych, a w razie stwierdzenia nieprawidłowości podejmował działania korygujące, a gdy te okażą się nieskuteczne – również sankcyjne. Trzeba więc zdecydować, kto w praktyce będzie podejmował takie decyzje. Jest to rozstrzygnięcie zarządcze, a nie systemowe: sprzedaż rzadko chce odpowiadać za uniemożliwienie agentowi wykonywania czynności. Bez jednoznacznego przypisania tej odpowiedzialności portal może powstać, ale decyzje nadal nie będą podejmowane.
- Obszar analityczny przekłada pojęcie „nadzoru” na konkretne działania, które można udokumentować: weryfikację warunków wykonywania czynności agencyjnych i realizacji obowiązku szkoleniowego, porównanie danych w rejestrze agentów ze stanem faktycznym oraz kontrolę materiałów marketingowych agenta. Na tym etapie ujawnia się również kwestia, która przesądza o zakresie rozwiązania: OFWCA nie jest stroną umowy z zakładem – jest nią agent. Wobec własnych pracowników dystrybucji zakład może bezpośrednio uniemożliwić wykonywanie czynności, natomiast wobec OFWCA działa za pośrednictwem agenta. Wyjątkiem jest sytuacja, w której OFWCA nie spełnia warunków wpisu do rejestru – wtedy reakcja powinna być natychmiastowa i prowadzić do złożenia wniosku o wykreślenie. To dwa różne procesy, a nie jeden przycisk w portalu.
- Obszar techniczny pozwala ustalić, skąd będą pochodzić dane zasilające portal i kto będzie je wprowadzał. Czy zaświadczenia o szkoleniach będą trafiać z platformy e-learningowej zakładu, czy z systemów kilkudziesięciu agentów – w kilkudziesięciu różnych formatach? Czy dane tej samej OFWCA można jednoznacznie powiązać w rejestrze agentów, systemie prowizyjnym i systemie sprzedażowym? I czy multiagencja współpracująca z ośmioma zakładami będzie ręcznie wprowadzać te same dane do każdego z ośmiu portali? Jeśli nie, duże multiagencje będą wymagały integracji systemowej, a portal będzie służył przede wszystkim mniejszym agentom.
W tym miejscu zwykle dochodzi do korekty zakresu. Portal, który wydawał się oczywistym rozwiązaniem, nie wystarcza do osiągnięcia celu – to tylko jeden z kilku kanałów pozyskiwania danych. Tym, co naprawdę trzeba zaprojektować, jest warstwa dowodowa: możliwy do odtworzenia zapis tego, kto przeprowadził weryfikację, czego dotyczyła, kiedy się odbyła i jaki był jej wynik. Taki zapis musi być dostępny na żądanie organu nadzoru. Zmiana definicji celu na tym poziomie po podpisaniu umowy oznacza przeprojektowanie modelu danych. Przed jej podpisaniem – jedynie zmianę akapitu w specyfikacji.
Dopiero połączenie wniosków z tych trzech obszarów pokazuje, czy projekt jest wykonalny i ma sens biznesowy przy przyjętych założeniach. Ma to szczególne znaczenie, gdy termin jest narzucony z zewnątrz i nieprzesuwalny. Jeśli zakres trzeba korygować już w trakcie budowy, w harmonogramie nie ma już miejsca na ponowne zaprojektowanie rozwiązania.
Gdzie jeszcze sprawdza się Discovery?
Ten sam mechanizm – analiza projektu w trzech obszarach – sprawdza się też przy innych przedsięwzięciach IT w ubezpieczeniach, na przykład przy:
- skróceniu czasu wdrażania zmian taryfowych z kwartałów do dni,
- zapewnieniu wielokanałowości bez silosów między kanałem agencyjnym, direct i bancassurance,
- automatyzacji rozliczeń prowizji z siecią sprzedaży – z uwzględnieniem progów premiowych, korekt i nieopisanych dotąd wyjątków,
- budowie elastyczności produktowej, która pozwala wprowadzać nowe warianty bez wielomiesięcznych projektów IT.
W każdym z tych przypadków Discovery pozwala odpowiedzieć na to samo pytanie: czy deklarowany cel opiera się na zweryfikowanych założeniach architektonicznych i jasno opisanych regułach biznesowych, czy pozostaje jedynie życzeniem zapisanym w RFP – bez potwierdzenia, że jest wykonalny.
Co towarzystwo ubezpieczeniowe zyskuje dzięki Discovery?
W żadnym z tych przypadków problem nie wynika z braku kompetencji którejkolwiek ze stron, lecz z tego, że kluczowe pytania – o architekturę, kompletność reguł biznesowych i rzeczywistą złożoność integracji – są zadawane zbyt późno.
Podstawową rolą Discovery nie jest tworzenie nowych wymagań, lecz weryfikacja tych, które już istnieją – zanim zostaną zapisane w umowie i staną się podstawą prac deweloperskich na dużą skalę. Dla towarzystwa ubezpieczeniowego oznacza to konkretne korzyści: mniej zmian zakresu w trakcie realizacji, mniej sporów o interpretację wymagań oraz wycenę, która po trzech miesiącach pracy nadal odpowiada rzeczywistemu zakresowi projektu.
Po zakończeniu Discovery cały pakiet materiałów zostaje do dyspozycji klienta – niezależnie od tego, kto zrealizuje projekt. Jeśli zakład wybierze innego dostawcę albo powierzy prace własnym zespołom, materiały nadal będą użyteczne. Każdy oferent wycenia wtedy ten sam, precyzyjnie opisany zakres, więc oferty można rzetelnie porównać.
Discovery nie musi wydłużać projektu – jego rezultaty są bezpośrednią podstawą prac deweloperskich, a nie dodatkowym materiałem obok właściwej realizacji. To niewielka inwestycja czasu w zamian za dużo mniejsze ryzyko na dalszych etapach. Właśnie dlatego w ubezpieczeniach – gdzie jeden proces bywa współwłasnością kilku funkcji biznesowych i kilku kanałów dystrybucji – ten etap szczególnie się opłaca.
Jesteśmy zespołem specjalistów pracujących głównie przy projektach dla sektora finansowego. Na blogu dzielimy się wiedzą z realizowanych projektów: omawiamy technologie, analizujemy podejścia do wdrożeń i pokazujemy, co sprawdza się w praktyce. Tworzymy materiały, które pomagają lepiej rozumieć IT i podejmować świadome decyzje, zarówno po stronie biznesu, jak i zespołów technologicznych.
