Szablon danych dotyczących obsługi roszczeń
Szablon danych dotyczących obsługi roszczeń
- Zalecane atrybuty do zebrania
- Działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z Guidewire ClaimCenter
Atrybuty obsługi roszczeń
| 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 | |||
Działania w procesie obsługi roszczeń
| 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 | |||
Instrukcje ekstrakcji danych
Kroki
- Sprawdzenie wymagań wstępnych: Upewnij się, że mają Państwo wymagane uprawnienia i dane logowania do bazy hurtowni danych Guidewire DataHub / InfoCenter z dostępem tylko do odczytu. Sprawdź, czy zadania ETL zasilające hurtownię danych dotyczących roszczeń działają poprawnie i czy dane są aktualne.
- Połączenie z bazą danych: Użyj standardowego klienta SQL, takiego jak DBeaver, SQL Server Management Studio lub podobne narzędzie, aby połączyć się z serwerem hurtowni danych.
- Poznanie schematu: Przed uruchomieniem pełnego zapytania zapoznaj się ze schematem hurtowni. Znajdź główne tabele dotyczące roszczeń, szkód, działań i transakcji finansowych. Nazwy kluczowych tabel często kończą się na _dim (wymiar) lub _fact (fakt). Dzięki temu można sprawdzić nazwy tabel i kolumn użyte w skrypcie.
- Przygotowanie zapytania SQL: Skopiuj cały skrypt SQL z sekcji zapytania do edytora zapytań klienta SQL.
- Uzupełnienie wartości zastępczych: Dokładnie przejrzyj skrypt i zastąp wszystkie wartości zastępcze. Dotyczy to nazwy bazy danych lub schematu, np. [YourDataMart], parametrów zakresu dat ('[StartDate]', '[EndDate]') oraz wartości konfiguracyjnych specyficznych dla systemu, takich jak wzorce działań i kody statusów.
- Uruchomienie zapytania: Uruchom zmodyfikowane zapytanie SQL w hurtowni danych. Czas wykonania zależy od wybranego zakresu dat i ilości danych w systemie.
- Wstępna kontrola danych: Po zakończeniu zapytania sprawdź pierwszych kilkaset wierszy wyników. Upewnij się, że kolumny ClaimID, ActivityName i EventTime zawierają oczekiwane wartości oraz że wyniki obejmują różne typy działań.
- Eksport do CSV: Wyeksportuj wszystkie wyniki z klienta SQL do pliku CSV. Nadaj mu opisową nazwę, na przykład guidewire_claimcenter_event_log.csv.
- Przygotowanie pliku dla ProcessMind: Zapisz plik CSV w kodowaniu UTF-8. Sprawdź, czy zawiera wiersz nagłówkowy zgodny z aliasami kolumn w zapytaniu SQL. Plik jest gotowy do przesłania do ProcessMind.
Konfiguracja
- Źródło danych: hurtownia danych dotyczących roszczeń Guidewire DataHub/InfoCenter. Jest to wstępnie zagregowana, wymiarowa baza danych przeznaczona do raportowania i analiz, odrębna od produkcyjnej bazy ClaimCenter działającej na bieżąco.
- Wymagane uprawnienia: dostęp tylko do odczytu do bazy SQL, na której działa hurtownia danych. Potrzebne będą nazwa użytkownika, hasło i dane połączenia, takie jak adres serwera i nazwa bazy danych.
- Stan zadań ETL: poprawność ekstrakcji zależy od terminowego i prawidłowego działania zadań ETL Guidewire zasilających hurtownię. Sprawdź czas ostatniego udanego uruchomienia, aby ocenić aktualność danych.
- Filtrowanie według zakresu dat: zapytanie zawiera klauzule WHERE z wartościami zastępczymi '[StartDate]' i '[EndDate]'. Warto zacząć od krótkiego zakresu, na przykład 3–6 miesięcy, aby nie obciążać systemu. Filtr daty jest stosowany do pola CreateTime roszczenia.
- Wartości zależne od konfiguracji: Guidewire można w dużym stopniu konfigurować. Należy dostosować wartości w klauzulach WHERE do ustawień organizacji. Dotyczy to:
- nazw ActivityPattern, np. 'fnol', 'investigation', 'Request additional information'
- kodów ClaimStatus, ExposureStatus i CloseReason, np. 'denied', 'closed'
- kodów TransactionStatus, np. 'pendingapproval', 'approved', 'issued'
- Wydajność: odpytywanie dużych tabel historii lub audytu może obciążać zasoby. W przypadku bardzo dużych zbiorów warto uruchamiać zapytanie poza godzinami szczytu. Sprawdź, czy kolumny ClaimID lub ClaimNumber mają indeksy w odpowiednich tabelach.
Przykładowe zapytanie sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed'; Kroki
- Sprawdź, czy organizacja ma aktywny udział danych Guidewire Cloud Data Access (CDA) w Snowflake dla środowiska ClaimCenter. Uzyskaj od administratora Guidewire Cloud identyfikator konta Snowflake, bazę danych, schemat, warehouse, rolę, metodę uwierzytelniania i zatwierdzoną konfigurację sieci.
- Sprawdź dokładne obiekty i kolumny CDA udostępnione w ramach udziału. Schematy i nazwy kolumn CDA mogą się różnić zależnie od dzierżawcy, wersji, konfiguracji i modelu udostępniania danych. Zastąp każdy ujęty w nawiasy kwadratowe symbol zastępczy obiektu lub kolumny odpowiednim elementem ze swojego środowiska. Nie zakładaj, że nazwy encji operacyjnych ClaimCenter są udostępniane w Snowflake bez zmian.
- Ustal źródła danych dotyczące utworzenia roszczenia, historii przypisań, utworzenia szkody, transakcji rezerw, działań, historii statusów szkód, historii statusów płatności i historii statusów roszczeń. Jeśli udział nie udostępnia tabel historii ani rekordów audytowych, skonfiguruj zatwierdzone źródło, które zachowuje poprzednią wartość, nową wartość, znacznik czasu zdarzenia i wykonawcę każdej wymaganej zmiany stanu.
- Połącz się z udziałem CDA w Snowflake za pomocą autoryzowanego klienta Snowflake, arkusza, notebooka lub narzędzia do wykonywania zapytań SQL. W miarę możliwości użyj roli tylko do odczytu. Ustaw w zapytaniu początkowy i końcowy znacznik czasu analizy za pomocą [Start timestamp] i [End timestamp]. Zastosuj zatwierdzony filtr firmy lub jednostki biznesowej za pomocą [Company filter].
- Zastąp symbole zastępcze źródeł w zapytaniu zweryfikowanymi nazwami obiektów i kolumn CDA. Zapytanie jawnie tworzy wiersze dla wszystkich 14 wymaganych działań: Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed i Claim Reopened.
- Uruchom zapytanie i sprawdź schemat wyników. Wynik musi zawierać kolumny ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus i LossCause. ProcessMind wymaga kolumn ClaimID, ActivityName i EventTime. Zachowaj osobny wiersz dla każdego zdarzenia, nie agreguj zdarzeń według roszczenia.
- Przed eksportem sprawdź znaczniki czasu, zmiany statusów, zmiany przypisań, obsługę duplikatów i liczbę działań. Upewnij się, że znaczniki czasu zdarzeń używają jednej strefy czasowej. Jeśli kilka odrębnych działań biznesowych ma ten sam znacznik czasu, pozostaw je w osobnych wierszach.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym obsługiwanym przez ProcessMind formacie tabelarycznym. Zmapuj ClaimID jako identyfikator case, ActivityName jako działanie, a EventTime jako znacznik czasu zdarzenia. Pozostałe zalecane atrybuty dodaj jako atrybuty zdarzeń. Prześlij plik do ProcessMind bez dodawania działań wywnioskowanych poza zakresem tej ekstrakcji.
Konfiguracja
- Połączenie i uprawnienia: Korzystaj z udziału danych Snowflake udostępnionego przez Guidewire, używając autoryzowanego konta, roli, warehouse i połączenia sieciowego Snowflake. Z perspektywy odbiorcy CDA zapewnia dostęp tylko do odczytu. Wymagane uprawnienia zależą od konfiguracji dzierżawcy i mogą obejmować możliwość odpytywania udostępnionej bazy danych oraz określonych schematów lub widoków.
- Konfiguracja obiektów źródłowych: Zastąp wszystkie odwołania w nawiasach kwadratowych obiektami zweryfikowanymi w udziale CDA. Zapytanie nie zakłada uniwersalnych nazw tabel ani kolumn ClaimCenter, ponieważ struktury CDA różnią się zależnie od wersji i dzierżawcy.
- Zakres dat: Na potrzeby weryfikacji i analizy operacyjnej zacznij od okresu od trzech do sześciu miesięcy. Szerszy zakres zastosuj dopiero po sprawdzeniu pojemności warehouse, okresu przechowywania historii zdarzeń i akceptowalnego czasu wykonania zapytania. Filtruj rekordy źródłowe według właściwego znacznika czasu zdarzenia, a nie tylko daty utworzenia roszczenia, aby nie pominąć późniejszych działań.
- Wymagane kolumny wynikowe: Każdy wiersz zdarzenia musi zawierać niepuste wartości ClaimID, ActivityName i EventTime. ActivityName musi używać dokładnych etykiet wymaganych przez model procesu w ProcessMind.
- Zalecane kolumny wynikowe: Uwzględnij AssignedAdjuster, ClaimType, ClaimStatus i LossCause. Jeśli to możliwe, pobierz te wartości ze stanu z chwili zdarzenia. Jeśli dostępne są tylko wartości bieżące, opisz to ograniczenie, ponieważ atrybuty historyczne mogą nie odzwierciedlać stanu z chwili zdarzenia.
- Filtry: Zastosuj [Company filter] dopiero po potwierdzeniu, która kolumna właściwa dla danego dzierżawcy odpowiada firmie, organizacji, jednostce biznesowej lub podmiotowi prawnemu. Nie filtruj według typu dokumentu, chyba że konfiguracja ClaimCenter udostępnia zweryfikowane pole typu dokumentu związane z wymaganymi działaniami.
- Historia zdarzeń: Do identyfikacji zmian przypisań, rozpoczęcia dochodzenia, żądań informacji, decyzji dotyczących odpowiedzialności, statusów płatności i ponownego otwarcia roszczeń potrzebne są dane historyczne lub audytowe. Same tabele bieżącego stanu nie pozwalają wiarygodnie odtworzyć wcześniejszych zdarzeń.
- Usuwanie duplikatów: Jeśli to możliwe, użyj zweryfikowanego identyfikatora zdarzenia źródłowego. Zapytanie wykorzystuje ROW_NUMBER jako konfigurowalne zabezpieczenie. Nie usuwaj duplikatów wyłącznie na podstawie ClaimID i znacznika czasu, jeśli różne działania mogą zgodnie z procesem wystąpić w tym samym czasie.
- Wydajność: Ogranicz zakres dat, wybieraj tylko wymagane kolumny, filtruj każde źródło według znacznika czasu zdarzenia i użyj warehouse Snowflake o odpowiedniej wielkości. W przypadku dużych wolumenów warto przygotować zweryfikowany widok zdarzeń lub ekstrakcję przyrostową.
- Strefa czasowa: Ujednolić EventTime do jednej udokumentowanej strefy czasowej. Przed załadowaniem dziennika zdarzeń sprawdź, czy znaczniki czasu CDA są zapisane w UTC, czasie lokalnym czy w jednym z wariantów typu timestamp w Snowflake.
- Wymagania wstępne: Sprawdź, czy udział obejmuje wymagane dane finansowe, dotyczące działań, przypisań, szkód, płatności i historii statusów ClaimCenter oraz czy zasady przechowywania danych zachowują wymagane zmiany historyczne.
Przykładowe zapytanie sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Kroki
- Sprawdź, czy bezpośredni dostęp do odczytu lokalnej operacyjnej bazy danych Guidewire ClaimCenter jest zatwierdzony, czy udokumentowano platformę bazy danych i wersję schematu oraz czy dostępne jest połączenie tylko do odczytu. Nie odpytuj produkcyjnej bazy danych bez zatwierdzonego okna ekstrakcji.
- Ustal fizyczne tabele i kolumny używane w danej implementacji ClaimCenter. Dopasuj encje roszczeń, szkód, działań, przypisań, rezerw, płatności, historii statusów oraz użytkowników lub grup do symboli zastępczych w zapytaniu. Ponieważ nazwy fizyczne i struktury audytowe różnią się zależnie od implementacji i wersji, zastępuj symbole zastępcze dopiero po sprawdzeniu ich w katalogu bazy danych i modelu danych ClaimCenter.
- Określ okres ekstrakcji za pomocą [Start date parameter] i [End date parameter]. Jeśli zmiany statusu, zakończenie zadań lub transakcje finansowe mogą być rejestrowane poza głównym okresem utworzenia roszczenia, uwzględnij nakładający się zakres, na przykład jeden lub dwa dni przed datą początkową.
- Uruchom całe zapytanie SQL z uprawnieniami tylko do odczytu. Każde działanie jest zwracane jako osobny wiersz zdarzenia. Po załadowaniu ProcessMind nie będzie wywnioskowywać zdarzeń. Zdarzenia wywnioskowane ze zmian pól są tworzone w zapytaniu SQL na podstawie odpowiednich rekordów historii lub audytu.
- Sprawdź mapowanie źródeł dla każdego działania. Potwierdź, że utworzenie roszczenia opiera się na pierwszym zapisanym rekordzie Claim, przypisanie na zmianach przypisania, utworzenie szkody na rekordach jej utworzenia, rezerwa początkowa na pierwszej transakcji rezerwy dla każdej szkody, dochodzenie i żądania informacji na rekordach działań, odpowiedzialność na skonfigurowanej zmianie statusu szkody, rozliczenie na statusie płatności oczekującej na zatwierdzenie, a zatwierdzenie i realizacja płatności na odpowiadających im stanach audytowych transakcji finansowych.
- Uporządkuj wyniki zgodnie z wymaganą strukturą dziennika zdarzeń. ClaimID musi być identyfikatorem case, ActivityName musi zawierać dokładnie jedną z czternastu udokumentowanych nazw działań, a EventTime musi być znacznikiem czasu. Zachowaj zalecane atrybuty, w tym AssignedAdjuster, ClaimType, ClaimStatus i LossCause, jeśli pozwala na to mapowanie źródeł.
- Sprawdź duplikaty i kolejność zdarzeń. Jeśli źródło zawiera kilka wierszy audytu dla tej samej zmiany biznesowej, zastosuj właściwy dla danej implementacji klucz deduplikacji w odpowiednim wyrażeniu tabelarycznym. Nie łącz odrębnych zdarzeń biznesowych o różnych znacznikach czasu lub identyfikatorach źródłowych.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym obsługiwanym przez ProcessMind formacie tabelarycznym. Dodaj wiersz nagłówkowy z kolumnami ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus i LossCause. Upewnij się, że znaczniki czasu zawierają informację o strefie czasowej albo konsekwentnie używają udokumentowanej strefy bazy danych. Prześlij plik do ProcessMind i zmapuj ClaimID jako identyfikator case, ActivityName jako działanie, a EventTime jako znacznik czasu zdarzenia.
Konfiguracja
- Dostęp do bazy danych: Użyj konta tylko do odczytu z uprawnieniami do wymaganych tabel operacyjnych ClaimCenter, tabel historii, tabel działań i tabel transakcji finansowych. Do ekstrakcji nie przyznawaj uprawnień do zapisu, modyfikacji schematu ani administracyjnych.
- Mapowanie schematu: Zastąp symbole zastępcze [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] i powiązane wartości nazwami zweryfikowanymi w docelowej implementacji. Nie zakładaj, że logiczna nazwa encji Guidewire jest nazwą fizycznej tabeli w bazie danych.
- Zakres dat: Zacznij od danych z trzech do sześciu miesięcy. Użyj [Start date parameter] i [End date parameter]. Uwzględnij nakładający się zakres, jeśli zdarzenia mogą być rejestrowane po utworzeniu roszczenia lub jeśli ponownie otwarte roszczenia obejmują kilka okresów raportowych.
- Filtry: Filtry [Company Code filter], [Document Type filter], jurysdykcji, linii biznesowej i inne filtry specyficzne dla organizacji stosuj dopiero po potwierdzeniu fizycznych kolumn i ich znaczenia biznesowego. Nie pomijaj roszczeń bez płatności lub szkody, ponieważ są potrzebne do pełnej analizy cyklu życia.
- Nazwy działań: Zachowaj dokładnie czternaście wartości ActivityName zdefiniowanych w zapytaniu, aby ProcessMind otrzymywał spójne etykiety zdarzeń.
- Znaczenie zdarzeń: Działania opisane jako wywnioskowane są tworzone w SQL na podstawie zmian statusu, przypisań, historii lub działań w źródle. Po załadowaniu danych ProcessMind nie będzie wyprowadzać tych zdarzeń z innych wierszy.
- Wydajność: Ogranicz okres ekstrakcji, wybieraj tylko wymagane kolumny, filtruj tabele źródłowe przed łączeniem i sprawdź indeksy identyfikatorów roszczeń i szkód, znaczników czasu zdarzeń, pól statusu oraz identyfikatorów transakcji. Jeśli to możliwe, duże ekstrakcje wykonuj na replice raportowej.
- Spójność: Użyj poziomu izolacji transakcji odpowiedniego do raportowania i ustal spójny punkt odcięcia ekstrakcji. Nie odczytuj tabel w trakcie częściowego zatwierdzania partii finansowej ani masowej aktualizacji statusów.
- Strefy czasowe: Udokumentuj strefę czasową bazy danych i przed eksportem przelicz wszystkie znaczniki czasu źródłowego na jedną uzgodnioną strefę. Nie łącz czasu lokalnego aplikacji z czasem serwera bazy danych.
- Wymagania wstępne: Sprawdź dostępność wymaganych modułów ClaimCenter, uprawnień finansowych, historii audytu lub retencji oraz połączenia z bazą danych. Jeśli historia lub dane audytowe nie są przechowywane, powiązanych działań wywnioskowanych nie da się wiarygodnie odtworzyć.
- Konfiguracja weryfikacji: Przy każdym eksporcie zapisuj wersję ClaimCenter, platformę bazy danych, mapowanie schematu, czas ekstrakcji, parametry dat, filtry i liczbę wierszy.
Przykładowe zapytanie sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; 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.
Karta kredytowa nie jest wymagana, konfiguracja zajmuje tylko kilka minut.