Integrowanie systemów informatycznych zajmuje dużo czasu i – z różnych powodów – rzadko mieści się w pierwotnie zakładanym budżecie. Czy tak musi być zawsze? A może istnieje rozwiązanie, które pozwoli znacznie przyspieszyć i uprościć ten proces? Czy mógłby nim być wspólny dla wszystkich podmiotów standard wymiany danych ubezpieczeniowych?

Technologia web services jest środkiem umożliwiającym zdalne (za pośrednictwem sieci internetowej) wykorzystywanie przez systemy informatyczne usług, które działają na innych serwerach czy winnych aplikacjach. Dzięki zastosowaniu web services systemy mogą ze sobą „rozmawiać” niezależnie od technologii i języków programowania, w których zostały napisane.

Czaso- i kosztochłonność

Integracja jest zadaniem długotrwałym i kosztownym, ale przynoszącym olbrzymie korzyści (o których wspominaliśmy w „Gazecie Ubezpieczeniowej” nr 48/2019). Na czym polega jej trudność? Poniższe zestawienie ma jedynie zasygnalizować, co i dlaczego wpływa na czaso- i kosztochłonność przedsięwzięcia.

Mapowanie modelu danych, procesów biznesowych i słowników jednej organizacji na inne. Jeśli chcemy, aby systemy ze sobą „rozmawiały”, musimy przetłumaczyć im procesy biznesowe i model danych, czyli rodzaje obiektów, opisujące je atrybuty i zasady posługiwania się nimi – bo każda organizacja ma swoje, inaczej zdefiniowane, zaprojektowane i ułożone. Są jeszcze słowniki. Skąd inżynier ma wiedzieć, że hasło X w słowniku jednej organizacji oznacza to samo co Y u drugiej? W języku naturalnym daną rzecz można określić różnymi słowami albo wręcz przeciwnie – coś, co brzmi podobnie, może oznaczać coś zupełnie innego. Z tego powodu prace przy integracji nie są trywialne, wymagają nie tylko zaangażowania osób technicznych, ale również ścisłej współpracy z pracownikami biznesowymi, którzy posiadają wiedzę merytoryczną w zakresie objętym integracją. Powstanie wspólnego standardu wymiany danych byłoby kamieniem milowym w integracji systemów ubezpieczeniowych.

Usługi często są niedokładnie udokumentowane i co jakiś czas modyfikowane. Dokumentacja techniczna jest piętą achillesową branży informatycznej. Często projekty trwają dłużej, niż zakładano, więc nie wystarcza już czasu na spisanie, co i jak zostało zaimplementowane, a braków w dokumentacji – w przeciwieństwie do funkcjonalności rozwiązania – nie widać na pierwszy rzut oka. Problemy pojawiają się później. Analogicznie sprawa wygląda z wprowadzaniem modyfikacji –zmiany w kodzie są, ale dokumentacja o nich milczy, a w najlepszym wypadku jest opatrzona enigmatycznym komentarzem. To wszystko powoduje liczne trudności podczas integracji systemów. Jedna strona opiera się na otrzymanej dokumentacji, dostosowuje się do niej, a później okazuje się, że testy integracyjne nie przechodzą…

Konieczność ścisłej współpracy IT i biznesu.Nie da się technicznie „przetłumaczyć” sposobu działania jednego systemu na drugi bez szczegółowej wiedzy dziedzinowej. Problemem jest dostęp do pracowników biznesowych organizacji, którzy – oprócz wypełniania codziennych obowiązków – muszą poświęcić czas na rozmowy i spotkania z inżynierami. Często zdarza się, że biznes jest zbyt obciążony „normalną” pracą i nie daje rady w sposób zadowalający dla IT zaangażować się w projekt integracyjny.

Konieczne jest również opracowanie zasad obsługi błędów, walidacji i warunków brzegowych, przygotowanie ich dla nowego bytu w postaci zintegrowanych systemów. Może się okazać, że integracja spowoduje także konieczność dopisania jakichś walidacji w pierwotnych aplikacjach, ponieważ pojawią się nowe przypadki ich użycia.

Każdy zakład ubezpieczeń czy dystrybutor ma swój indywidualny model danych i własne procesy. Powoduje to, że przy realizacji projektów integracyjnych za każdym razem integrator musi opracowywać od podstaw model integracji. Czyli mówiąc obrazowo – ile firm, tyle „języków” i każda zintegrowana para „języków” musi przejść przez cały proces analizy, wdrażania, testowania, stabilizacji… od nowa. I to kosztuje.

Standard komunikacji dla rynku ubezpieczeń

A może kluczem do rozwiązania większości problemów byłaby standaryzacja procesów wymiany danych? Standardy bardzo ułatwiają codzienne życie. Na przykład międzynarodowe środowisko biznesowe porozumiewa się po angielsku. Porty USB – niezależnie od tego, kto wyprodukuje sprzęt wyposażony w port USB, działa on w taki sam sposób. Mało tego, można go wykorzystać do podłączenia różnych innych urządzeń dowolnych producentów: smartfona, myszki, klawiatury… Standardami są kody SWIFT niezbędne do wykonania przelewów zagranicznych. UFG również narzucił zakładom ubezpieczeń wzorzec komunikacji w zakresie przekazywania danych o polisach – i wszyscy się do niego dostosowali. To są standardy globalne, ale istnieją również lokalne, jak na przykład jednolity, zamodelowany w systemie CRM, proces sprzedaży w danej firmie.

A gdyby udało się wprowadzić na polskim rynku ubezpieczeniowym jednolity standard wymiany danych między podmiotami na wzór amerykańskiego ACORD-a (Association for Cooperative Operations Research and Development, www.acord.org)?Do tego uniwersalny model danych. Wszyscy w branży operują na procesach według tego samego schematu oraz na bardzo podobnym zestawie danych, z którego można wyłonić wspólny zbiór. Gdybyśmy mieli standard, to większość ww. problemów z integracją systemów w ogóle nie miałaby racji bytu, a sam proces integracji byłby dużo łatwiejszy i przede wszystkim powtarzalny.

Potrzebny jest standard, który ułatwi przepływ danych między wszystkimi zainteresowanymi stronami w procesach i transakcjach związanych z ubezpieczeniami – od kalkulacji poprzez polisy i rozliczenia po obsługę szkód i roszczeń. Dzięki temu cała branża będzie mogła działać bardziej wydajnie, poprawić jakość danych i zminimalizować liczbę błędów, czyli realnie zaoszczędzić. W przypadku standardu ACORD oszczędności to ok. miliarda dolarów dla globalnego przemysłu ubezpieczeniowego.

Wady i zalety

Standard może z czasem stać się dojrzałym produktem, bo będzie miał wielu użytkowników, będzie stale rozwijany i weryfikowany na różnych frontach i w rozmaitych sytuacjach, co przełoży się na jakość i możliwości elastycznego zastosowania w biznesie. Tak jak np. Wikipedia, która z upływem lat – dzięki zaangażowaniu wielu użytkowników – stała się bardzo wiarygodnym źródłem informacji.

Jednak wprowadzenie standaryzacji wymiany danych ubezpieczeniowych ma też swoje wady. Opracowanie standardu wymaga czasu i zaangażowania wszystkich uczestników rynku – zakładów ubezpieczeń, brokerów, agencji i dostawców oprogramowania. Późniejsze zmiany w standardzie wprowadza się powoli, bo należy je najpierw wdrożyć centralnie, a następnie rozpropagować – tak więc time-to-market może być dłuższy, ale długofalowe korzyści niewspółmiernie wyższe.

Gdybyśmy rozpoczęli opracowywanie standardu, należałoby postawić pytanie: gdzie powinien się kończyć? W jakim stopniu powinien wyznaczać reguły, a co zostawić firmie go implementującej? Rynek ubezpieczeń nie jest nowy i można przewidzieć, które jego elementy będą zmienne w czasie, a dzięki temu zbudować standard elastyczny, który w pewnych obszarach będzie pozostawiał użytkownikom konfigurowalność, więc nie ograniczy możliwości budowania przewag konkurencyjnych w zakresie procesów i wykorzystywanych danych.

Jakie będą korzyści z wdrożenia standardu wymiany danych na polskim rynku ubezpieczeń?

• niższe (może nawet o rząd wielkości) koszty integracji dla dystrybutorów – budujemy jeden konektor, który pasuje do wszystkich ubezpieczycieli;
• zakłady ubezpieczeń nie będą musiały angażować się w projekty integracyjne i dokumentowanie swoich serwisów;
• dla klienta końcowego mogą być dostępne wszystkie produkty z rynku w różnych porównywarkach (dużo prostsze zbudowanie i utrzymanie porównywarki);
• cały ekosystem ubezpieczycieli i dystrybutorów działałby w jednolity i dopracowany sposób w dojrzałym standardzie, co oznacza stabilność, wysoką jakość danych i bezpieczeństwo – wystarczy raz dobrze zaprojektować standard.

Wśród przeciwników unifikacji może się pojawić teza, że obecnie integracja systemów stanowi przewagę konkurencyjną. Jednak czy tak stricte techniczna rzecz, która po prostu musi działać, powinna być wyróżnikiem? Oszczędzając czas i środki w tym obszarze, można się skoncentrować na prawdziwych innowacjach.

Jacek Dymczak
dyrektor rozwoju obszaru ubezpieczeń VSoft SA

Agnieszka Kruszyna
analityk VSoft SA