Szablon danych dotyczących obsługi roszczeń

Guidewire ClaimCenter
Szablon danych dotyczących obsługi roszczeń

Szablon danych dotyczących obsługi roszczeń

Ten szablon pomoże przygotować dane do usprawnienia obsługi roszczeń. Zawiera listę atrybutów, które warto zbierać, działań do śledzenia oraz wskazówki dotyczące ekstrakcji danych. Dzięki niemu można zgromadzić informacje potrzebne do analizy procesu.
  • Zalecane atrybuty do zebrania
  • Działania do śledzenia
  • Wskazówki dotyczące ekstrakcji danych z Guidewire ClaimCenter
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi roszczeń

Te zalecane pola danych pomogą zbudować kompletny dziennik zdarzeń i skutecznie analizować workflow obsługi roszczeń.
3 Wymagane 4 Zalecane 14 Opcjonalne
Nazwa Opis
Claim ID
ClaimID
Unikatowy identyfikator każdego roszczenia ubezpieczeniowego, pełniący funkcję głównego identyfikatora sprawy.
Opis

Claim ID jest podstawą analizy procesu obsługi roszczeń, ponieważ jednoznacznie identyfikuje każdą sprawę od zgłoszenia do zamknięcia. Łączy wszystkie powiązane czynności, dokumenty, płatności i komunikację, zapewniając pełny i spójny obraz cyklu życia roszczenia.

W process mining każde zdarzenie w zbiorze danych jest powiązane z Claim ID, co pozwala odtworzyć przebieg procesu od początku do końca. Jest to niezbędne do analizy czasu realizacji, wykrywania wariantów procesu i śledzenia sprawy między działami oraz likwidatorami szkód.

Dlaczego to ważne

To podstawowy identyfikator łączący wszystkie powiązane zdarzenia. Dzięki niemu można prześledzić i przeanalizować cały przebieg pojedynczego roszczenia.

Skąd pobrać

To klucz główny w Guidewire ClaimCenter, zwykle dostępny jako Claim.ClaimNumber lub podobne pole w podstawowym obiekcie Claim.

Przykłady
000-123-45678000-987-65432001-456-11223
Czas zdarzenia
EventTime
Dokładna data i godzina wystąpienia czynności.
Opis

Ten znacznik czasu wskazuje dokładny moment zarejestrowania czynności w systemie. Jest podstawą każdej analizy procesu uwzględniającej czas.

Chronologiczne uporządkowanie wartości EventTime dla pojedynczego identyfikatora szkody pozwala odtworzyć przebieg procesu. Różnice czasu między kolejnymi zdarzeniami służą do obliczania czasu cyklu, czasu oczekiwania i czasu realizacji. Wskaźniki te są niezbędne do analizy wydajności, identyfikowania wąskich gardeł i monitorowania SLA.

Dlaczego to ważne

Ten znacznik czasu pozwala uporządkować zdarzenia, obliczać czas cyklu i czas trwania oraz wykrywać opóźnienia w procesie.

Skąd pobrać

Dane te znajdują się zwykle w tabelach historii lub audytu Guidewire ClaimCenter, w polu takim jak „CreateTime” lub „UpdateTime”.

Przykłady
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Nazwa czynności
ActivityName
Nazwa czynności biznesowej lub zdarzenia, które wystąpiło w określonym momencie obsługi szkody.
Opis

Ten atrybut opisuje konkretny krok lub etap procesu obsługi szkody, na przykład „Utworzenie szkody”, „Rozpoczęcie dochodzenia” lub „Wypłata odszkodowania”. Sekwencja tych czynności dla danego identyfikatora szkody tworzy przebieg procesu.

Analiza kolejności, częstotliwości i czasu trwania poszczególnych czynności stanowi podstawę process mining. Pozwala odkrywać modele procesów, identyfikować wąskie gardła i pętle poprawek oraz analizować odchylenia od przebiegu procesu.

Dlaczego to ważne

Określa kroki procesu, umożliwiając wizualizację map procesów oraz analizę ich przebiegu i wąskich gardeł.

Skąd pobrać

Zazwyczaj dane pochodzą z tabel zdarzeń lub dzienników audytowych w ClaimCenter. Konkretne zdarzenia systemowe lub zmiany statusu przypisuje się do standardowych nazw czynności.

Przykłady
Utworzenie roszczeniaPodjęcie decyzji o odpowiedzialnościZlecenie wypłatyZamknięcie roszczenia
Przyczyna szkody
LossCause
Konkretna przyczyna zdarzenia powodującego szkodę, na przykład kolizja, pożar lub zalanie.
Opis

Ten atrybut dostarcza szczegółowych informacji o przyczynie zgłoszenia szkody. Przyczyna często określa wymagane czynności dochodzeniowe, rodzaj potrzebnych ekspertów i ogólną złożoność sprawy.

Analiza procesu według przyczyny szkody może ujawnić ukryte zależności. Na przykład szkody spowodowane zalaniem mogą częściej wymagać ponownej pracy lub zaangażowania specjalistów niż szkody związane z kradzieżą. Takie wnioski pomagają opracować bardziej wyspecjalizowane i sprawniejsze procedury obsługi.

Dlaczego to ważne

Określa charakter szkody i pozwala analizować wpływ różnych przyczyn na przebieg i czas trwania procesu.

Skąd pobrać

To standardowe pole obiektu Claim, zwykle nazwane „LossCause”.

Przykłady
KolizjaPożarZalanieKradzież
Przypisany likwidator szkody
AssignedAdjuster
Nazwa lub identyfikator użytkownika przypisanego do obsługi szkody albo konkretnej czynności.
Opis

Ten atrybut wskazuje likwidatora odpowiedzialnego za szkodę w danym momencie. Likwidator może być przypisany do całej szkody lub do konkretnych zadań w ramach jej obsługi.

Analiza według przypisanego likwidatora ma znaczenie dla równoważenia obciążenia pracą, zarządzania wynikami i identyfikowania potrzeb szkoleniowych. Pomaga odpowiedzieć na pytania: „Którzy likwidatorzy mają najwięcej spraw?”, „Czy wyniki likwidatorów się różnią?” i „Czy praca jest rozdzielana równomiernie?”.

Dlaczego to ważne

Pokazuje udział poszczególnych użytkowników, umożliwiając analizę obciążenia pracą i porównanie wyników oraz identyfikację wąskich gardeł związanych z zasobami.

Skąd pobrać

Dostępne w obiekcie Claim lub Exposure w ClaimCenter, często powiązane z obiektem User, na przykład Claim.Assignee.

Przykłady
j.doem.smiths.jones
Rodzaj szkody
ClaimType
Kategoria szkody ubezpieczeniowej, na przykład komunikacyjna, majątkowa lub z tytułu odpowiedzialności cywilnej.
Opis

Rodzaj szkody to podstawowa kategoria określana na podstawie linii biznesowej lub charakteru straty. Poszczególne rodzaje szkód często podlegają innym procesom, różnią się stopniem złożoności i wymaganiami prawnymi.

Podział analizy procesu według rodzaju szkody jest niezbędny, aby uzyskać miarodajne wnioski. Pozwala porównywać wyniki procesu w różnych liniach biznesowych, identyfikować wąskie gardła charakterystyczne dla danego rodzaju szkód i dostosowywać działania usprawniające do specyfiki każdej kategorii.

Dlaczego to ważne

Pozwala podzielić szkody na kategorie, ponieważ różne ich rodzaje, na przykład komunikacyjne i majątkowe, często podlegają innym procesom i mają różne cele dotyczące wyników.

Skąd pobrać

Wartość pochodzi z obiektu Policy lub Claim w ClaimCenter i jest często określana na podstawie kodu Line of Business (LOB).

Przykłady
Szkody komunikacyjne osób fizycznychSzkody majątkowe przedsiębiorstwOdpowiedzialność cywilna ogólnaOdszkodowania pracownicze
Status szkody
ClaimStatus
Ogólny status szkody w chwili wystąpienia zdarzenia, na przykład otwarta, zamknięta lub odrzucona.
Opis

Ten atrybut określa ogólny stan szkody. Najważniejsze statusy to „Otwarta”, „Zamknięta”, „Odrzucona” i „Ponownie otwarta”. Status końcowy szkody jest istotnym miernikiem wyniku.

Śledzenie zmian statusu szkody pomaga określić ważne etapy i wyniki procesu. Umożliwia ustalenie końcowego rozstrzygnięcia szkody, obliczenie odsetka odrzuconych spraw i analizę częstotliwości ponownego otwierania zamkniętych szkód, co często wskazuje na problemy z procesem lub niezadowolenie klientów.

Dlaczego to ważne

Wskazuje wynik obsługi szkody, co pozwala analizować odsetek odrzuconych spraw, sposób zamykania szkód i częstotliwość ich ponownego otwierania.

Skąd pobrać

To podstawowe pole obiektu Claim, zwykle nazwane „State” lub „Status”.

Przykłady
OtwartaZamkniętaOdrzuconaPonownie otwarta
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy czynność została zakończona.
Opis

Czas zakończenia oznacza moment ukończenia czynności, zwłaszcza zadań o mierzalnym czasie trwania, takich jak „Dochodzenie” lub „Weryfikacja dokumentów”. Wiele czynności analizowanych w process mining jest chwilowych, więc wystarczy dla nich StartTime. Czynności z wyraźnym początkiem i końcem lepiej opisywać za pomocą obu znaczników czasu.

Ten atrybut pozwala dokładnie obliczyć czas realizacji czynności, oddzielając go od czasu oczekiwania. Ułatwia wskazanie konkretnych zadań, które zajmują dużo czasu, zamiast jedynie odnotowywać długie przerwy między kolejnymi krokami.

Dlaczego to ważne

Pozwala dokładnie zmierzyć czas realizacji czynności i oddzielić go od czasu oczekiwania.

Skąd pobrać

Czas zakończenia może wymagać wyznaczenia na podstawie kolejnego zdarzenia, które logicznie kończy daną czynność, na przykład zmiany statusu z „W toku” na „Zakończono”.

Przykłady
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Czy czynność jest zautomatyzowana
IsAutomated
Flaga wskazująca, czy czynność wykonał automatycznie system, czy użytkownik.
Opis

Ten atrybut logiczny odróżnia czynności wykonywane przez system, na przykład automatyczne tworzenie rezerw lub generowanie korespondencji, od czynności wykonywanych ręcznie przez likwidatora.

Analiza tego atrybutu pozwala ocenić poziom automatyzacji procesu obsługi szkód. Ułatwia wykrywanie miejsc wymagających ręcznej interwencji, ocenę skuteczności inicjatyw związanych z obsługą bezpośrednią oraz wskazywanie nowych możliwości automatyzacji przez identyfikację powtarzalnych zadań opartych na regułach, które obecnie wykonują ludzie.

Dlaczego to ważne

Odróżnia czynności wykonywane przez system od tych wykonywanych przez ludzi, co pozwala analizować automatyzację i wykrywać wąskie gardła związane z pracą ręczną.

Skąd pobrać

Wartość często trzeba wyznaczyć. Na przykład zdarzenia rejestrowane przez ogólnego użytkownika „system” można oznaczyć jako zautomatyzowane.

Przykłady
truefalse
Czy wystąpiła ponowna praca
IsRework
Flaga wskazująca, czy czynność należy do pętli poprawek, czyli powrotu do wcześniejszego etapu procesu.
Opis

Ten obliczany atrybut oznacza czynności należące do pętli poprawek. Na przykład jeśli proces przechodzi z etapu „Zakończenie dochodzenia” z powrotem do „Rozpoczęcie dochodzenia”, drugie wystąpienie czynności „Rozpoczęcie dochodzenia” zostanie oznaczone jako ponowna praca.

Identyfikacja ponownej pracy jest niezbędna do wykrywania nieefektywności procesu i problemów z jakością. Dashboard dotyczący ponownej pracy i częstotliwości odrzuceń wykorzystuje ten wskaźnik do określenia, jak często obsługa szkód odbiega od optymalnego przebiegu. Analiza przyczyn ponownej pracy może znacząco poprawić jakość i szybkość procesu.

Dlaczego to ważne

Wskazuje nieefektywności procesu i problemy z jakością, oznaczając czynności należące do pętli poprawek.

Skąd pobrać

Wartość jest obliczana w narzędziu process mining na podstawie sekwencji czynności dla każdej sprawy.

Przykłady
truefalse
Data ostatniej aktualizacji
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone lub wyodrębnione z systemu źródłowego.
Opis

Ten atrybut zawiera znacznik czasu ostatniego pobrania danych z systemu źródłowego. To pole metadanych pozwala ocenić aktualność analizy.

Dashboardy i analizy powinny wyraźnie prezentować tę informację, aby użytkownicy wiedzieli, jak aktualne są dane. Dzięki temu można ocenić, czy wnioski odzwierciedlają bieżący stan operacji, czy opierają się na starszych danych.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak bieżąca jest analiza procesu.

Skąd pobrać

Wartość jest generowana i zapisywana podczas procesu ETL jako znacznik czasu załadowania danych.

Przykłady
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Data zdarzenia powodującego szkodę
LossDate
Data wystąpienia zdarzenia lub straty, która była przyczyną zgłoszenia szkody.
Opis

Data zdarzenia powodującego szkodę to dzień, w którym doszło do zdarzenia, na przykład wypadku samochodowego lub uszkodzenia mienia, będącego podstawą zgłoszenia. Nie jest to data zgłoszenia ani utworzenia szkody.

Czas między datą zdarzenia a czynnością „Utworzenie szkody”, nazywany opóźnieniem w zgłoszeniu, jest ważnym KPI. Jego analiza pozwala lepiej zrozumieć zachowania klientów i skuteczność kanałów pierwszego zgłoszenia szkody.

Dlaczego to ważne

Dostarcza informacji o przyczynie zgłoszenia i pozwala analizować opóźnienie w zgłoszeniu, czyli czas od zdarzenia do zgłoszenia szkody.

Skąd pobrać

To podstawowe pole daty w obiekcie Claim, często nazwane „LossDate”.

Przykłady
2023-05-102023-04-202023-05-28
Docelowa data rozstrzygnięcia szkody
ResolutionTargetDate
Data, do której zgodnie z wewnętrznymi lub regulacyjnymi SLA należy rozstrzygnąć szkodę.
Opis

Docelowa data rozstrzygnięcia szkody to termin zamknięcia sprawy, często ustalany na podstawie takich czynników jak jurysdykcja, rodzaj szkody i warunki polisy. Służy jako punkt odniesienia przy ocenie wyników i zgodności.

Ten atrybut jest niezbędny do tworzenia dashboardów i KPI dotyczących realizacji SLA. Porównanie rzeczywistej daty czynności „Zamknięcie szkody” z terminem docelowym pozwala automatycznie oznaczać opóźnione szkody, mierzyć odsetek spraw zamkniętych w terminie i wskazywać rodzaje szkód lub działy, które nie realizują założonych celów.

Dlaczego to ważne

To punkt odniesienia przy ocenie realizacji umowy o gwarantowanym poziomie usług (SLA) i identyfikowaniu szkód zagrożonych opóźnieniem.

Skąd pobrać

Może to być pole niestandardowe lub wartość wyznaczana na podstawie reguł biznesowych skonfigurowanych w ClaimCenter, być może powiązanych z określonymi wskaźnikami szkody.

Przykłady
2023-06-142023-07-202023-08-28
Dział
Department
Jednostka biznesowa lub dział odpowiedzialny za obsługę czynności związanej ze szkodą.
Opis

Ten atrybut wskazuje dział lub zespół, do którego należy przypisany likwidator, na przykład „Szkody komunikacyjne”, „Szkody majątkowe” lub „Zespół dochodzeń specjalnych”. Określa kontekst organizacyjny procesu.

Analiza według działu pozwala ocenić wyniki procesu na poziomie organizacji. Ułatwia wykrywanie opóźnień przy przekazywaniu spraw między działami, porównywanie efektywności zespołów i lepsze przydzielanie zasobów w obszarze obsługi szkód.

Dlaczego to ważne

Określa kontekst organizacyjny, umożliwiając porównanie wyników różnych zespołów i wykrywanie problemów przy przekazywaniu spraw między działami.

Skąd pobrać

Informacje te są zwykle powiązane z profilem przypisanego użytkownika lub grupy w ClaimCenter.

Przykłady
Dział szkód komunikacyjnychZespół szkód majątkowychZespół dochodzeń specjalnych (SIU)
Jurysdykcja
JurisdictionState
Stan lub jurysdykcja właściwa dla szkody, określająca wymagania regulacyjne.
Opis

Ten atrybut określa jurysdykcję prawną, na przykład stan USA, w której rozpatrywana jest szkoda. Przepisy ubezpieczeniowe mogą się znacznie różnić w zależności od jurysdykcji, wpływając na wymagane kroki procesu, terminy komunikacji i dokumentację.

Atrybut ten ma istotne znaczenie dla monitorowania zgodności. Analiza procesu według jurysdykcji pozwala sprawdzić, czy spełniane są lokalne wymagania regulacyjne. Może też wyjaśnić różnice w czasie cyklu lub przebiegu procesu wynikające z ograniczeń prawnych, a nie z nieefektywności operacyjnej.

Dlaczego to ważne

Ma istotne znaczenie dla analizy zgodności, ponieważ przepisy różnią się w zależności od jurysdykcji i wpływają na proces obsługi szkód.

Skąd pobrać

Standardowe pole obiektu Claim, zwykle nazwane „JurisdictionState”.

Przykłady
CANYTXFL
Kwota wypłaty
PaymentAmount
Rzeczywista kwota wypłacona w ramach danej czynności płatniczej.
Opis

Ten atrybut zapisuje kwotę każdej wypłaty dokonanej w ramach szkody. W trakcie obsługi jednej szkody może nastąpić kilka wypłat.

Informacja ta jest niezbędna do analizy finansowej w process mining. Można jej użyć do śledzenia łącznej kwoty wypłat dla każdej szkody, analizy czasu zatwierdzania wypłat w zależności od kwoty oraz powiązania nieefektywności procesu z wynikami finansowymi. Na przykład długi czas obsługi szkody może wiązać się z wyższą łączną kwotą wypłat.

Dlaczego to ważne

Rejestruje transakcje finansowe związane ze szkodą, umożliwiając analizę kwot wypłat i ich związku z czynnościami w procesie.

Skąd pobrać

Dane znajdują się w obiektach związanych z płatnościami, powiązanych ze szkodą, często w tabeli transakcji lub czeków.

Przykłady
4500.00125000.00500.00
Ponowna prośba o informacje
RepeatedInfoRequestFlag
Flaga wskazująca, czy czynność „Prośba o dodatkowe informacje” wystąpiła więcej niż raz dla tej samej szkody.
Opis

Ta flaga logiczna przyjmuje wartość true, jeśli dla szkody wystąpiła więcej niż jedna czynność „Prośba o dodatkowe informacje”. Taka sytuacja często wskazuje na nieefektywność w początkowym etapie zbierania informacji.

Atrybut ten bezpośrednio wspiera KPI dotyczący częstotliwości ponownych próśb o informacje. Pomaga określić skalę problemu niepełnego zebrania informacji na początku, który może powodować znaczne opóźnienia i frustrację klientów. Analiza szkód oznaczonych tą flagą może pomóc ulepszyć listy kontrolne i procedury dla likwidatorów, tak aby od razu prosili o wszystkie potrzebne informacje.

Dlaczego to ważne

Wskazuje nieefektywności wynikające z niepełnego zebrania informacji za pierwszym razem, które prowadzi do opóźnień i ponownej pracy.

Skąd pobrać

Wartość jest obliczana w narzędziu process mining przez zliczenie wystąpień czynności „Prośba o dodatkowe informacje” dla każdej sprawy.

Przykłady
truefalse
Rodzaj polisy
PolicyType
Konkretny rodzaj polisy ubezpieczeniowej, z której zgłoszono szkodę.
Opis

Rodzaj polisy zapewnia bardziej szczegółową klasyfikację niż rodzaj szkody. Określa konkretny produkt ubezpieczeniowy, na przykład „Ubezpieczenie domu”, „Ubezpieczenie pojazdów firmowych” lub „Odpowiedzialność cywilna w cyberprzestrzeni”. Taki poziom szczegółowości może ujawnić różnice w procesie związane z konkretnymi produktami.

Analiza procesu według rodzaju polisy pomaga wykrywać nieefektywności charakterystyczne dla danego produktu. Na przykład szkody zgłaszane w ramach nowo wprowadzonej polisy mogą podlegać mniej dojrzałemu procesowi, co prowadzi do opóźnień. Wyniki takiej analizy mogą pomóc w projektowaniu produktów i standaryzacji procesów.

Dlaczego to ważne

Umożliwia analizę procesu dla konkretnych produktów ubezpieczeniowych i pomaga wykrywać różnice w obsłudze wynikające ze specyfiki polisy.

Skąd pobrać

Informacje te znajdują się w obiekcie Policy powiązanym z obiektem Claim.

Przykłady
Ubezpieczenie domu od wielu ryzykOdpowiedzialność cywilna z tytułu ubezpieczenia pojazdów firmowychUbezpieczenie ładunków w transporcie śródlądowym
Status SLA
SLAState
Informuje, czy szkodę zamknięto przed upływem docelowego terminu rozstrzygnięcia.
Opis

Ten obliczany atrybut określa kategorię realizacji SLA dla każdej zamkniętej szkody. Jest wyznaczany przez porównanie znacznika czasu czynności „Zamknięcie szkody” z docelową datą rozstrzygnięcia.

Atrybut ten bezpośrednio wspiera dashboard „Realizacja docelowego terminu rozstrzygnięcia szkody”, upraszczając analizę do czytelnych kategorii, takich jak „W terminie” i „Po terminie”. Ułatwia filtrowanie i agregowanie danych w celu obliczenia ogólnego poziomu realizacji SLA oraz zejścia o poziom niżej, aby zbadać przyczyny opóźnień.

Dlaczego to ważne

Jasno określa kategorię realizacji SLA, ułatwiając filtrowanie, agregowanie i analizę terminowości.

Skąd pobrać

Pole obliczane: IF (ActualCloseDate <= ResolutionTargetDate, 'W terminie', 'Po terminie').

Przykłady
W terminiePo terminie
System źródłowy
SourceSystem
System, z którego wyodrębniono dane.
Opis

Ten atrybut wskazuje źródło danych o zdarzeniach. W nowoczesnym środowisku firmowym zdarzenia związane ze szkodą mogą pochodzić z wielu systemów, na przykład z systemu podstawowego, takiego jak Guidewire, systemu zarządzania dokumentami lub portalu klienta.

Wskazanie systemu źródłowego ma istotne znaczenie dla zarządzania danymi, rozwiązywania problemów z ich niespójnością i zrozumienia środowiska technologicznego procesu. Ułatwia odróżnienie głównych kroków procesu od czynności pomocniczych wykonywanych w systemach zewnętrznych.

Dlaczego to ważne

Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi i analiz obejmujących wiele zintegrowanych systemów.

Skąd pobrać

Zazwyczaj jest to stała wartość dodawana podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL).

Przykłady
Guidewire ClaimCenter v10Customer Portal APIDocumentum
Zgłoszona kwota szkody
ClaimedAmount
Łączna kwota początkowo zgłoszona przez ubezpieczającego.
Opis

Ten atrybut określa wartość straty zgłoszoną przez osobę zgłaszającą szkodę. Często jest to wstępny szacunek, który może się zmienić w trakcie dochodzenia i ustalania rezerw.

Analiza zgłoszonej kwoty pozwala podzielić szkody według ich wpływu finansowego. Szkody o wysokiej wartości często wymagają bardziej rygorystycznego i złożonego procesu niż szkody o niskiej wartości. Porównanie przebiegu obsługi w różnych przedziałach kwotowych może wskazać, jak uprościć obsługę mniejszych szkód lub wprowadzić ściślejsze kontrole dla większych.

Dlaczego to ważne

Pozwala podzielić szkody według wartości finansowej, ponieważ szkody o wysokiej wartości mogą podlegać innym, bardziej złożonym procesom.

Skąd pobrać

Informacja ta może nie występować w jednym polu. Można ją wyznaczyć na podstawie początkowych szacunków strat zapisanych dla poszczególnych ekspozycji.

Przykłady
5000.00150000.00750.50
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi roszczeń

To najważniejsze kroki procesu i istotne etapy, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odkrywać i analizować przebieg obsługi roszczeń.
7 Zalecane 7 Opcjonalne
Działanie Opis
Odrzucenie roszczenia
Oznacza ostateczną decyzję o odrzuceniu roszczenia i kończy proces. Zdarzenie jest ustalane na podstawie zmiany statusu roszczenia na zamknięty oraz przyczyny „Denied”.
Dlaczego to ważne

To ważne zdarzenie końcowe. Analiza częstotliwości odrzuceń, ich przyczyn i ścieżek procesu prowadzących do odrzucenia pomaga wykryć problemy ze zgłoszeniem roszczenia, dochodzeniem lub interpretacją warunków polisy.

Skąd pobrać

Zdarzenie jest ustalane na podstawie zmiany pola State w tabeli cc_claim na „Closed” oraz wartości „Denied” lub podobnej w polu CloseReason. Znacznikiem czasu zdarzenia jest CloseDate.

Rejestrowanie

Filtruj zmiany statusu roszczenia na „Closed”, dla których kod przyczyny wskazuje odrzucenie.

Typ zdarzenia inferred
Ustalenie rezerwy początkowej
Oznacza utworzenie pierwszej transakcji rezerwy finansowej dla ekspozycji, która szacuje potencjalny koszt roszczenia. To istotne zdarzenie finansowe jest rejestrowane jawnie.
Dlaczego to ważne

Ten etap jest ważny dla analizy finansowej i oceny, jak szybko szacowana jest potencjalna odpowiedzialność. Opóźnienia mogą utrudniać planowanie i raportowanie finansowe.

Skąd pobrać

Zdarzenie jest rejestrowane w chwili utworzenia pierwszego rekordu cc_reserveline powiązanego z ekspozycją w ramach roszczenia. Znacznik czasu zdarzenia pochodzi z pola CreateTime transakcji.

Rejestrowanie

Znajdź najwcześniejszy znacznik czasu utworzenia wszystkich pozycji rezerwy dla ekspozycji w danym roszczeniu.

Typ zdarzenia explicit
Utworzenie ekspozycji
To zdarzenie oznacza utworzenie ekspozycji, czyli określonego potencjalnego zobowiązania lub rodzaju szkody w ramach roszczenia, na przykład uszkodzenia pojazdu lub obrażeń ciała. W Guidewire jest to jawne zdarzenie.
Dlaczego to ważne

Ekspozycje stanowią podstawę podziału i analizy roszczeń. Śledzenie ich tworzenia pomaga zrozumieć różnice w przebiegu procesu zależne od złożoności roszczenia i rodzaju szkody.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie pola CreateTime nowego rekordu w tabeli cc_exposure. Każdy rekord jest powiązany z jednym Claim ID.

Rejestrowanie

Ustal znacznik czasu utworzenia nowego rekordu w tabeli obiektu Exposure.

Typ zdarzenia explicit
Utworzenie roszczenia
To zdarzenie oznacza pierwsze zgłoszenie szkody (FNOL) i oficjalne utworzenie nowego rekordu roszczenia w Guidewire ClaimCenter. Jest rejestrowane w chwili pierwszego zapisania nowego obiektu Claim w bazie danych.
Dlaczego to ważne

Jako główne zdarzenie początkowe ta czynność jest niezbędna do pomiaru czasu obsługi roszczenia od początku do końca. Stanowi punkt odniesienia dla wszystkich późniejszych KPI dotyczących wyników i czasu trwania.

Skąd pobrać

To jawne zdarzenie odczytywane z pola CreateTime tabeli cc_claim. Wyzwala je utworzenie nowego rekordu z unikatowym Claim ID.

Rejestrowanie

Ustal znacznik czasu utworzenia nowego rekordu w podstawowej tabeli obiektu Claim.

Typ zdarzenia explicit
Zamknięcie roszczenia
Oznacza pomyślne zamknięcie roszczenia po zakończeniu wszystkich czynności i wypłat. To główne zdarzenie kończące proces, ustalane na podstawie zmiany głównego statusu roszczenia.
Dlaczego to ważne

Jako główne zdarzenie końcowe ta czynność jest niezbędna do obliczenia czasu obsługi od początku do końca i pomiaru realizacji SLA. Oznacza zakończenie cyklu życia roszczenia.

Skąd pobrać

Zdarzenie jest ustalane na podstawie zmiany pola State w tabeli cc_claim na „Closed”. Znacznikiem czasu zdarzenia jest CloseDate w rekordzie roszczenia.

Rejestrowanie

Ustal, kiedy główne pole statusu roszczenia zostaje zmienione na „Closed”.

Typ zdarzenia inferred
Zatwierdzenie wypłaty
Oznacza formalne zatwierdzenie wypłaty rozliczenia. To ważne zdarzenie audytowe jest rejestrowane jawnie, gdy transakcję zatwierdza uprawniony użytkownik.
Dlaczego to ważne

Ten ważny etap umożliwia realizację końcowej wypłaty. Analiza czasu przed tą czynnością i po niej pomaga ustalić, czy opóźnienia wynikają z workflow akceptacji, czy z dostępności kierownika.

Skąd pobrać

To często jawne zdarzenie zapisane w tabeli cc_history i powiązane z obiektem cc_check lub cc_transaction. Rejestruje zmianę statusu z „Pending Approval” na „Approved”.

Rejestrowanie

Śledź zmianę statusu konkretnej transakcji płatniczej na „Approved”.

Typ zdarzenia explicit
Zlecenie wypłaty
Ta czynność oznacza końcowy etap procesu płatności, w którym wypłata zostaje oficjalnie zlecona i przekazana do systemu finansowego. Jest to jawnie rejestrowana transakcja finansowa.
Dlaczego to ważne

Ta czynność jest niezbędna do pomiaru sprawności realizacji wypłat. Pozwala odróżnić opóźnienia w zatwierdzaniu od opóźnień w faktycznym przekazaniu środków.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie pola IssueDate lub zmiany statusu na „Issued” albo „Submitted” w obiekcie cc_check lub cc_transaction. Często jest to jawne zdarzenie ze znacznikiem czasu.

Rejestrowanie

Ustal wartość IssueDate lub znacznik czasu zmiany statusu rekordu płatności na „Issued”.

Typ zdarzenia explicit
Obliczenie kwoty rozliczenia
To zdarzenie oznacza ustalenie kwoty rozliczenia, która nie została jeszcze zatwierdzona do wypłaty. Można je ustalić na podstawie utworzenia płatności ze statusem „Pending Approval”.
Dlaczego to ważne

Oznacza przejście od oceny do wypłaty. Rozpoczyna pomiar KPI „Czas oczekiwania na zatwierdzenie wypłaty” i pozwala wykryć opóźnienia w procesie akceptacji.

Skąd pobrać

Zdarzenie jest ustalane na podstawie pola CreateTime rekordu cc_check lub cc_transaction, którego początkowy status to „Pending Approval” albo podobny status poprzedzający „Approved”.

Rejestrowanie

Ustal, kiedy utworzono rekord płatności lub transakcji ze statusem poprzedzającym zatwierdzenie.

Typ zdarzenia inferred
Otrzymanie dodatkowych informacji
Oznacza zakończenie procesu pozyskiwania dodatkowych informacji. Zdarzenie jest rejestrowane, gdy odpowiadająca mu czynność (zadanie) dotycząca prośby o informacje otrzyma status „Completed”.
Dlaczego to ważne

To zdarzenie końcowe dla KPI „Czas pozyskiwania dodatkowych informacji”. Długi czas między wysłaniem prośby a otrzymaniem odpowiedzi często opóźnia obsługę roszczenia.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie pola CloseTime rekordu cc_activity, którego ActivityPattern dotyczy prośby o informacje. Status czynności musi mieć wartość „Completed”.

Rejestrowanie

Ustal znacznik czasu zakończenia zadania dotyczącego pozyskania informacji z zewnątrz.

Typ zdarzenia explicit
Podjęcie decyzji o odpowiedzialności
Oznacza moment ustalenia odpowiedzialności lub winy w odniesieniu do ekspozycji. Zdarzenie jest zwykle ustalane na podstawie zmiany statusu obiektu Exposure.
Dlaczego to ważne

To ważny etap decyzyjny, od którego zależą rozliczenie i wypłata. Analiza czasu do podjęcia decyzji pomaga wykryć wąskie gardła na etapach dochodzenia i oceny.

Skąd pobrać

Zdarzenie jest ustalane na podstawie tabeli cc_history przez śledzenie zmiany pola State lub niestandardowego pola statusu odpowiedzialności w obiekcie cc_exposure. Znacznik czasu rekordu historii wskazuje czas zdarzenia.

Rejestrowanie

Monitoruj dzienniki audytowe lub tabele historii pod kątem zmian stanu ekspozycji lub statusu odpowiedzialności.

Typ zdarzenia inferred
Ponowne otwarcie roszczenia
Oznacza zmianę statusu roszczenia z „Closed” na „Open”, aby można było wykonać dodatkowe czynności. Zdarzenie jest ustalane na podstawie określonej sekwencji zmian statusu.
Dlaczego to ważne

Ta czynność oznacza konieczność ponownej pracy. Duża liczba ponownie otwieranych roszczeń może wskazywać na problemy z pierwotnym rozliczeniem, nieuwzględnione szkody lub inne nieprawidłowości procesu, które zwiększają koszty i obniżają wydajność.

Skąd pobrać

Zdarzenie jest ustalane na podstawie tabeli cc_history przez wykrycie zmiany pola State w obiekcie cc_claim z „Closed” z powrotem na „Open” lub inny aktywny status.

Rejestrowanie

Monitoruj główne pole statusu roszczenia pod kątem zmiany ze statusu zamkniętego na otwarty.

Typ zdarzenia inferred
Prośba o dodatkowe informacje
Oznacza wysłanie do osoby zgłaszającej roszczenie lub strony trzeciej prośby o dodatkowe informacje lub dokumenty. Zdarzenie jest zwykle rejestrowane jako jawnie utworzona czynność (zadanie) w ClaimCenter.
Dlaczego to ważne

Ta czynność rozpoczyna pomiar KPI „Czas pozyskiwania dodatkowych informacji”. Częste występowanie takich próśb może wskazywać na niekompletne zgłoszenia FNOL lub nieefektywne pozyskiwanie informacji.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie pola CreateTime rekordu cc_activity, którego ActivityPattern dotyczy prośby o dokumenty lub informacje od podmiotu zewnętrznego.

Rejestrowanie

Ustal, kiedy utworzono zadanie dotyczące pozyskania informacji z zewnątrz.

Typ zdarzenia explicit
Przypisanie roszczenia
Oznacza przypisanie roszczenia konkretnemu użytkownikowi (likwidatorowi szkód) lub grupie do obsługi. Zdarzenie jest zwykle wykrywane przez monitorowanie zmian pól przypisania w obiekcie Claim.
Dlaczego to ważne

Śledzenie przypisań jest niezbędne do analizy obciążenia likwidatorów szkód, wykrywania wąskich gardeł przy kierowaniu spraw i pomiaru czasu do pierwszego działania osoby odpowiedzialnej za sprawę.

Skąd pobrać

Zdarzenie jest ustalane na podstawie tabeli cc_history przez śledzenie zmian pól AssignedUser lub AssignedGroup powiązanych z konkretnym Claim ID. Znacznik czasu zmiany wskazuje, kiedy nastąpiło zdarzenie.

Rejestrowanie

Monitoruj dzienniki audytowe lub tabele historii pod kątem zmian pól przypisania roszczenia.

Typ zdarzenia inferred
Rozpoczęcie dochodzenia
Oznacza formalne rozpoczęcie etapu dochodzenia w sprawie roszczenia lub ekspozycji. Zdarzenie jest często ustalane na podstawie utworzenia pierwszej czynności (zadania) związanej z dochodzeniem w Guidewire.
Dlaczego to ważne

Ta czynność rozpoczyna ważny, często długotrwały etap procesu. Analiza czasu do rozpoczęcia dochodzenia i czasu jego trwania pozwala wykryć główne wąskie gardła.

Skąd pobrać

Zdarzenie jest ustalane na podstawie pola CreateTime rekordu cc_activity, którego ActivityPattern dotyczy dochodzenia, na przykład „Wstępne dochodzenie” lub „Kontakt ze świadkiem”.

Rejestrowanie

Ustal, kiedy po raz pierwszy utworzono zadanie o wzorcu lub temacie związanym z dochodzeniem.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Guidewire ClaimCenter

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane do analizy i lepiej poznać przebieg obsługi roszczeń. Już teraz zacznij usprawniać workflow.

Przyspiesz obsługę roszczeń i szybciej je rozpatruj

Ogranicz zaległości, zapobiegaj oszustwom i dąż do 70% obsługi bez ręcznej interwencji.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana, konfiguracja zajmuje tylko kilka minut.