Ihr Daten-Template für die Schadenbearbeitung
Ihr Daten-Template für die Schadenbearbeitung
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion aus Guidewire ClaimCenter
Attribute der Schadenbearbeitung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Die Bezeichnung der geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Schadenlebenszyklus eingetreten ist. | ||
| Beschreibung Dieses Attribut beschreibt einen bestimmten Schritt oder Meilenstein im Schadenbearbeitungsprozess, zum Beispiel „Schaden angelegt“, „Ermittlung begonnen“ oder „Zahlung veranlasst“. Die Abfolge dieser Aktivitäten für eine bestimmte Case-ID bildet den Prozessfluss. Die Analyse der Abfolge, Häufigkeit und Dauer zwischen Aktivitäten ist der Kern des Process Mining. Sie ermöglicht es, Prozessmodelle zu ermitteln, Engpässe zu identifizieren, Nacharbeitsschleifen aufzudecken und Prozessabweichungen zu analysieren. Warum das wichtig ist Damit werden die Prozessschritte festgelegt. So lassen sich Prozesslandkarten visualisieren sowie Prozessfluss und Engpässe analysieren. Woher beziehen Dieses Attribut wird in der Regel aus Ereignistabellen oder Audit-Protokollen in ClaimCenter abgeleitet, häufig indem bestimmte Systemereignisse oder Statusänderungen standardisierten Aktivitätsbezeichnungen zugeordnet werden. Beispiele Schadenfall angelegtHaftungsentscheidung getroffenZahlung angewiesenSchadenfall abgeschlossen | |||
| Ereigniszeitpunkt EventTime | Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieser Timestamp gibt den genauen Zeitpunkt an, zu dem eine Aktivität im System erfasst wurde. Er ist die Grundlage für alle zeitbezogenen Prozessanalysen. Anhand der chronologischen Reihenfolge der EventTime-Werte für eine einzelne Case-ID lässt sich der Prozessfluss rekonstruieren. Die Zeit zwischen aufeinanderfolgenden Ereignissen dient zur Berechnung von Zykluszeiten, Wartezeiten und Verarbeitungszeiten. Diese Kennzahlen sind entscheidend für die Leistungsanalyse, die Identifizierung von Engpässen und die SLA-Überwachung. Warum das wichtig ist Dieser Timestamp ist wichtig, um Ereignisse zu ordnen, Zykluszeiten und Dauern zu berechnen und Verzögerungen im Prozess zu erkennen. Woher beziehen Zu finden neben Ereignis- oder Aktivitätsdaten in den Verlaufs- oder Audit-Tabellen von Guidewire ClaimCenter, häufig als Feld „CreateTime“ oder „UpdateTime“. Beispiele 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Schaden-ID ClaimID | Die eindeutige Kennung jedes Versicherungsschadenfalls und die primäre Fallkennung. | ||
| Beschreibung Die Claim-ID ist die Grundlage für die Analyse von Schadenbearbeitungsprozessen. Sie identifiziert jeden Fall eindeutig von der Einreichung bis zum Abschluss. Sie verknüpft alle zugehörigen Aktivitäten, Dokumente, Zahlungen und Mitteilungen und ermöglicht so einen vollständigen, zusammenhängenden Überblick über den Lebenszyklus eines Schadenfalls. Beim Process Mining ist jedes Ereignis im Datensatz einer Claim-ID zugeordnet. Dadurch lässt sich der Prozessablauf von Anfang bis Ende rekonstruieren. Das ist entscheidend, um Zykluszeiten zu analysieren, Prozessvarianten zu erkennen und den Weg eines Schadenfalls durch verschiedene Abteilungen und Zuständigkeiten nachzuverfolgen. Warum das wichtig ist Dieser grundlegende Schlüssel verknüpft alle zugehörigen Ereignisse und ermöglicht es, den gesamten Ablauf eines einzelnen Schadenfalls nachzuverfolgen und zu analysieren. Woher beziehen Dies ist ein Primärschlüssel in Guidewire ClaimCenter. Er ist üblicherweise als Claim.ClaimNumber oder in einem ähnlichen Feld der zentralen Claim-Entität zu finden. Beispiele 000-123-45678000-987-65432001-456-11223 | |||
| Schadenart ClaimType | Die Kategorie des Versicherungsschadens, zum Beispiel Kfz, Sachschaden oder Haftpflicht. | ||
| Beschreibung Die Schadenart ordnet einen Schadenfall nach der Sparte oder der Art des Schadens ein. Je nach Schadenart gelten oft unterschiedliche Prozesse, Komplexitätsstufen und Vorschriften. Damit die Prozessanalyse aussagekräftig ist, sollte sie nach Schadenart segmentiert werden. So können Sie die Prozessleistung verschiedener Sparten vergleichen, spezifische Engpässe erkennen und Verbesserungsmaßnahmen auf die Besonderheiten der jeweiligen Schadenkategorie abstimmen. Warum das wichtig ist Ermöglicht die Segmentierung von Schadenfällen, da verschiedene Arten, etwa Kfz- und Sachschäden, oft unterschiedlichen Prozessen und Leistungszielen folgen. Woher beziehen Wird aus der Entität Policy oder Claim in ClaimCenter abgeleitet, häufig anhand des Line-of-Business-Codes (LOB). Beispiele Privater Kfz-SchadenGewerblicher SachschadenAllgemeine HaftpflichtArbeitsunfallversicherung | |||
| Schadenstatus ClaimStatus | Der Gesamtstatus des Schadenfalls zum Zeitpunkt des Ereignisses, zum Beispiel offen, abgeschlossen oder abgelehnt. | ||
| Beschreibung Dieses Attribut gibt den übergeordneten Status des Schadenfalls an. Zu den wichtigsten Statuswerten gehören „Offen“, „Abgeschlossen“, „Abgelehnt“ und „Wiedereröffnet“. Der endgültige Status eines Schadenfalls ist eine wichtige Ergebniskennzahl. Anhand von Änderungen des Schadenstatus lassen sich wichtige Prozessmeilensteine und Ergebnisse bestimmen. Der Status dient dazu, den endgültigen Ausgang eines Schadenfalls zu ermitteln, Ablehnungsquoten zu berechnen und zu analysieren, wie oft Schadenfälle nach dem Abschluss wiedereröffnet werden. Das kann auf Prozessprobleme oder Unzufriedenheit bei Kunden hindeuten. Warum das wichtig ist Gibt den Ausgang eines Schadenfalls an und ist wichtig für die Analyse von Ablehnungsquoten, Abschlussmustern und der Häufigkeit wiedereröffneter Fälle. Woher beziehen Ein zentrales Feld der Entität Claim, das in der Regel „State“ oder „Status“ heißt. Beispiele OffenAbgeschlossenAbgelehntWiedereröffnet | |||
| Schadenursache LossCause | Der konkrete Grund oder die Ursache des Schadensereignisses, zum Beispiel Kollision, Feuer oder Wasserschaden. | ||
| Beschreibung Dieses Attribut liefert genauere Informationen dazu, warum der Schadenfall gemeldet wurde. Die Schadenursache bestimmt häufig, welche Ermittlungsschritte erforderlich sind, welche Fachleute hinzugezogen werden müssen und wie komplex der Schadenfall insgesamt ist. Die Analyse nach Schadenursache kann verborgene Muster aufdecken. Bei Wasserschäden kann es beispielsweise häufiger zu Nacharbeit kommen oder mehr Fachleute erfordern als bei Diebstahlschäden. Diese Erkenntnisse helfen dabei, die Bearbeitung gezielter und effizienter zu gestalten. Warum das wichtig ist Liefert Kontext zur Art des Schadenfalls und ermöglicht die Analyse, wie verschiedene Schadenursachen den Prozessfluss und die Dauer beeinflussen. Woher beziehen Ein Standardfeld der Entität Claim, das in der Regel „LossCause“ heißt. Beispiele KollisionFeuerWasserschadenDiebstahl | |||
| Zugewiesener Sachbearbeiter AssignedAdjuster | Der Name oder die ID des Benutzers, der mit der Bearbeitung des Schadensfalls oder einer bestimmten Aktivität betraut ist. | ||
| Beschreibung Dieses Attribut gibt an, welcher Sachbearbeiter zu einem bestimmten Zeitpunkt für einen Schadenfall verantwortlich ist. Ein Sachbearbeiter kann dem gesamten Schadenfall oder einzelnen Aufgaben darin zugewiesen sein. Die Analyse nach zugewiesenem Sachbearbeiter ist wichtig, um die Arbeitslast auszugleichen, die Leistung zu steuern und Schulungsbedarf zu erkennen. Sie hilft bei Fragen wie: „Welche Sachbearbeiter haben die meisten Fälle?“, „Gibt es Leistungsunterschiede zwischen den Sachbearbeitern?“ und „Ist die Arbeit gleichmäßig verteilt?“ Warum das wichtig ist Erfasst die Beteiligung einzelner Benutzer und ermöglicht so die Analyse der Arbeitslast, den Leistungsvergleich und die Identifizierung ressourcenbedingter Engpässe. Woher beziehen In ClaimCenter in der Entität Claim oder Exposure verfügbar, häufig mit dem User-Objekt verknüpft, zum Beispiel Claim.Assignee. Beispiele j.doem.smiths.jones | |||
| Abteilung Department | Die Geschäftseinheit oder Abteilung, die für die Bearbeitung der Aktivität im Schadenfall zuständig ist. | ||
| Beschreibung Dieses Attribut gibt an, zu welcher Abteilung oder welchem Team der zugewiesene Sachbearbeiter gehört, zum Beispiel „Kfz-Schäden“, „Sachschäden“ oder „Sonderermittlungen“. Es ordnet den Prozess in einen organisatorischen Kontext ein. Die Analyse nach Abteilung ist wichtig, um die Prozessleistung auf Organisationsebene zu verstehen. Sie hilft dabei, Verzögerungen bei der Übergabe zwischen Abteilungen zu erkennen, die Effizienz verschiedener Teams zu vergleichen und Ressourcen im Schadenbereich gezielter einzusetzen. Warum das wichtig ist Ordnet den Prozess organisatorisch ein. So können Sie die Leistung verschiedener Teams vergleichen und Probleme bei Übergaben zwischen Abteilungen erkennen. Woher beziehen Diese Information ist in der Regel im Profil des zugewiesenen Benutzers oder der Gruppe in ClaimCenter hinterlegt. Beispiele Kfz-SchadenabteilungAbteilung für SachschädenSonderermittlungseinheit (SIU) | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob das System oder ein Benutzer eine Aktivität automatisch ausgeführt hat. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die ein System ausführt, etwa die automatische Bildung von Rückstellungen oder systemgenerierte Mitteilungen, und Aktivitäten, die ein Sachbearbeiter manuell erledigt. Die Analyse dieses Attributs ist wichtig, um den Automatisierungsgrad im Schadenbearbeitungsprozess zu verstehen. Sie hilft, Bereiche mit häufigen manuellen Eingriffen zu erkennen, die Wirksamkeit von Initiativen zur durchgängigen automatisierten Bearbeitung zu messen und weitere Automatisierungsmöglichkeiten zu finden, indem wiederkehrende, regelbasierte Aufgaben identifiziert werden, die derzeit von Mitarbeitenden erledigt werden. Warum das wichtig ist Unterscheidet zwischen systemgesteuerten und von Menschen ausgeführten Aktivitäten. Das ist wichtig für die Automatisierungsanalyse und die Identifizierung manueller Engpässe. Woher beziehen Dieser Wert muss häufig abgeleitet werden. Ereignisse, die beispielsweise von einem generischen „System“-Benutzer protokolliert werden, können als automatisiert gekennzeichnet werden. Beispiele truefalse | |||
| Endzeitpunkt EndTime | Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
| Beschreibung Der Endzeitpunkt gibt an, wann eine Aktivität abgeschlossen wurde. Das ist besonders bei Aufgaben mit messbarer Dauer wichtig, etwa bei einer „Ermittlung“ oder „Dokumentenprüfung“. Viele Aktivitäten im Process Mining sind punktuell, sodass der StartTime ausreicht. Aktivitäten mit einem klaren Anfang und Ende lassen sich jedoch besser mit beiden Timestamps abbilden. Mit diesem Attribut lässt sich die Verarbeitungszeit einer Aktivität genau berechnen und von der Wartezeit abgrenzen. So erkennen Sie, welche Aufgaben besonders viel Zeit beanspruchen, statt nur lange Verzögerungen zwischen Prozessschritten festzustellen. Warum das wichtig ist Damit lässt sich genau messen, wie lange eine Aktivität bis zum Abschluss dauert. So können Sie die Verarbeitungszeit von der Wartezeit unterscheiden. Woher beziehen Dieser Wert muss möglicherweise abgeleitet werden, indem ein nachfolgendes Ereignis ermittelt wird, das die Aktivität logisch abschließt, zum Beispiel eine Statusänderung von „In Bearbeitung“ zu „Abgeschlossen“. Beispiele 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Geforderter Betrag ClaimedAmount | Der Gesamtbetrag, den der Versicherungsnehmer zunächst als Schaden geltend macht. | ||
| Beschreibung Dieses Attribut gibt den Wert des Schadens an, den der Anspruchsteller gemeldet hat. Häufig handelt es sich um eine erste Schätzung, die sich im Verlauf der Prüfung und bei der Bildung von Rückstellungen ändern kann. Der geforderte Betrag ermöglicht es, Schadenfälle nach ihrer finanziellen Bedeutung zu segmentieren. Hochwertige Schadenfälle durchlaufen oft einen strengeren und komplexeren Prozess als Fälle mit geringem Wert. Der Vergleich verschiedener Betragsklassen kann zeigen, wie sich kleinere Fälle einfacher bearbeiten oder größere Fälle mit strengeren Kontrollen versehen lassen. Warum das wichtig ist Ermöglicht die Segmentierung von Schadenfällen nach ihrem finanziellen Wert, da Fälle mit hohen Beträgen oft anderen und komplexeren Prozessen folgen. Woher beziehen Diese Information liegt möglicherweise nicht als einzelnes Feld vor, sondern lässt sich aus den ersten Schadenschätzungen zu den Exposures ableiten. Beispiele 5000.00150000.00750.50 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut enthält den Timestamp des letzten Datenabrufs aus dem Quellsystem. Als Metadatenfeld ist es wichtig, um die Aktualität der Analyse beurteilen zu können. Dashboards und Analysen sollten diese Information gut sichtbar anzeigen, damit Benutzer wissen, wie aktuell die Daten sind. So lässt sich einschätzen, ob die Erkenntnisse den aktuellen Betriebszustand widerspiegeln oder auf älteren Daten beruhen. Warum das wichtig ist Gibt an, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand der Prozessanalyse einschätzen können. Woher beziehen Dieser Wert wird während des ETL-Prozesses erzeugt und gespeichert. Er gibt den Timestamp des Datenimports an. Beispiele 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
| Nacharbeit IsRework | Ein Kennzeichen dafür, ob eine Aktivität zu einer Nacharbeitsschleife gehört, also zu einer Rückkehr in eine frühere Prozessphase. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Aktivitäten, die Teil einer Nacharbeitsschleife sind. Führt der Prozess beispielsweise von „Ermittlung abgeschlossen“ zurück zu „Ermittlung begonnen“, wird die zweite Aktivität „Ermittlung begonnen“ als Nacharbeit gekennzeichnet. Nacharbeit zu erkennen ist entscheidend, um Ineffizienzen und Qualitätsprobleme im Prozess aufzudecken. Das Dashboard „Häufigkeit von Nacharbeit und Ablehnungen“ verwendet diese Kennzahl, um zu ermitteln, wie oft Schadenfälle vom idealen „Happy Path“ abweichen. Die Analyse der Ursachen für Nacharbeit kann die Prozessqualität und -geschwindigkeit deutlich verbessern. Warum das wichtig ist Macht Ineffizienzen und Qualitätsprobleme sichtbar, indem Aktivitäten, die zu einer Nacharbeitsschleife gehören, ausdrücklich gekennzeichnet werden. Woher beziehen Wird im Process-Mining-Tool berechnet, indem die Abfolge der Aktivitäten für jeden Case analysiert wird. Beispiele truefalse | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt an, aus welcher Quelle die Ereignisdaten stammen. In einer modernen Unternehmenslandschaft können schadenbezogene Ereignisse aus mehreren Systemen kommen, etwa aus einem Kernsystem wie Guidewire, einem Dokumentenmanagementsystem oder einem Kundenportal. Die Angabe des Quellsystems ist wichtig für die Data Governance, die Fehlersuche bei widersprüchlichen Daten und das Verständnis der technischen Systemlandschaft des Prozesses. Sie hilft dabei, zentrale Prozessschritte von unterstützenden Aktivitäten in angrenzenden Systemen zu unterscheiden. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance und Analysen, die mehrere integrierte Systeme umfassen. Woher beziehen Dieser Wert wird in der Regel während des ETL-Prozesses (Extraktion, Transformation und Laden) als statischer Wert hinzugefügt. Beispiele Guidewire ClaimCenter v10Customer Portal APIDocumentum | |||
| Schadendatum LossDate | Das Datum, an dem sich der Vorfall oder Schaden ereignet hat, der zur Meldung des Schadenfalls führte. | ||
| Beschreibung Das Schadendatum bezeichnet den Tag des tatsächlichen Ereignisses, zum Beispiel eines Autounfalls oder eines Sachschadens. Es unterscheidet sich vom Datum, an dem der Schadenfall gemeldet oder angelegt wurde. Die Zeit zwischen dem Schadendatum und der Aktivität „Schaden angelegt“ wird als Meldeverzug bezeichnet und ist eine wichtige KPI. Ihre Analyse kann Erkenntnisse zum Verhalten von Kunden und zur Wirksamkeit der Kanäle für die Erstmeldung eines Schadens liefern. Warum das wichtig ist Liefert wichtigen Kontext zur Entstehung des Schadenfalls und hilft, den Meldeverzug zu analysieren, also die Zeit zwischen dem Vorfall und der Schadenmeldung. Woher beziehen Ein grundlegendes Datumsfeld der Entität Claim, das häufig „LossDate“ heißt. Beispiele 2023-05-102023-04-202023-05-28 | |||
| SLA-Status SLAState | Gibt an, ob der Schadenfall bis zum Zieltermin für die Schadenregulierung abgeschlossen wurde. | ||
| Beschreibung Dieses berechnete Attribut gibt für jeden abgeschlossenen Schadenfall den Status der SLA-Einhaltung an. Es wird ermittelt, indem der Timestamp der Aktivität „Schaden abgeschlossen“ mit dem Zieltermin für die Schadenregulierung verglichen wird. Das Attribut unterstützt direkt das Dashboard „Einhaltung des Zieltermins für die Schadenregulierung“, indem es die Analyse in klare Kategorien wie „Fristgerecht“ oder „Verspätet“ unterteilt. So können Sie einfach filtern und aggregieren, um die allgemeine SLA-Einhaltungsquote zu berechnen und die Ursachen für Verzögerungen genauer zu untersuchen. Warum das wichtig ist Liefert ein eindeutiges, kategorisiertes Ergebnis zur SLA-Einhaltung. So lassen sich fristgerechte Bearbeitungen einfach filtern, aggregieren und analysieren. Woher beziehen Berechnetes Feld: IF (ActualCloseDate <= ResolutionTargetDate, 'Fristgerecht', 'Verspätet'). Beispiele FristgerechtVerspätet | |||
| Versicherungsprodukttyp PolicyType | Der konkrete Typ der Versicherungspolice, unter der der Schadenfall gemeldet wurde. | ||
| Beschreibung Der Versicherungsprodukttyp ermöglicht eine genauere Einordnung als die Schadenart und bezeichnet das konkrete Versicherungsprodukt, zum Beispiel „Wohngebäudeversicherung“, „gewerbliche Kfz-Versicherung“ oder „Cyber-Haftpflicht“. Diese Detailtiefe kann Prozessunterschiede sichtbar machen, die mit bestimmten Produkten zusammenhängen. Die Analyse nach Versicherungsprodukttyp hilft, Ineffizienzen bei einzelnen Produkten aufzudecken. Bei Schadenfällen zu einer neu eingeführten Police kann der Prozess beispielsweise noch weniger ausgereift sein und dadurch zu Verzögerungen führen. Die Analyse kann in die Produktgestaltung und die Standardisierung von Prozessen einfließen. Warum das wichtig ist Ermöglicht die Prozessanalyse für einzelne Versicherungsprodukte und hilft, Unterschiede bei der Bearbeitung anhand der jeweiligen Policenmerkmale zu erkennen. Woher beziehen Diese Information ist in der Entität Policy hinterlegt, die mit Claim verknüpft ist. Beispiele Mehrgefahrenversicherung für WohngebäudeGewerbliche Kfz-HaftpflichtTransportversicherung | |||
| Wiederholte Informationsanfrage RepeatedInfoRequestFlag | Ein Kennzeichen dafür, ob die Aktivität „Zusätzliche Informationen angefordert“ für denselben Schadenfall mehr als einmal aufgetreten ist. | ||
| Beschreibung Dieses boolesche Kennzeichen wird auf „true“ gesetzt, wenn die Aktivität „Zusätzliche Informationen angefordert“ für einen Schadenfall mehr als einmal auftritt. Das deutet häufig auf Ineffizienzen bei der ersten Informationsbeschaffung hin. Dieses Attribut unterstützt direkt die KPI „Quote wiederholter Informationsanfragen“. Es hilft, unvollständige erste Sachverhaltsaufnahmen zu quantifizieren, die zu erheblichen Verzögerungen und Unzufriedenheit bei Kunden führen können. Die Analyse entsprechend gekennzeichneter Schadenfälle kann dabei helfen, Checklisten und Vorgehensweisen für Sachbearbeiter zu verbessern, damit alle erforderlichen Informationen auf einmal angefordert werden. Warum das wichtig ist Zeigt Ineffizienzen auf, wenn Informationen nicht gleich beim ersten Mal vollständig erfasst werden und dadurch Verzögerungen und Nacharbeit entstehen. Woher beziehen Wird im Process-Mining-Tool berechnet, indem die Anzahl der Aktivitäten „Zusätzliche Informationen angefordert“ pro Case gezählt wird. Beispiele truefalse | |||
| Zahlungsbetrag PaymentAmount | Der tatsächlich für eine Zahlungsaktivität ausgezahlte Betrag. | ||
| Beschreibung Dieses Attribut erfasst den Betrag jeder einzelnen Zahlung zu einem Schadenfall. Im Verlauf eines Schadenfalls können mehrere Zahlungen erfolgen. Im Process Mining ist dieses Attribut für die Finanzanalyse wichtig. Damit lassen sich die Gesamtauszahlung pro Schadenfall verfolgen, Genehmigungszeiten für Zahlungen nach Betrag analysieren und Prozessineffizienzen mit finanziellen Ergebnissen in Beziehung setzen. So können Schadenfälle mit langen Zykluszeiten beispielsweise mit höheren Gesamtauszahlungen einhergehen. Warum das wichtig ist Erfasst die finanziellen Transaktionen innerhalb eines Schadenfalls und ermöglicht die Analyse von Zahlungsbeträgen und ihrem Zusammenhang mit Prozessaktivitäten. Woher beziehen Zu finden in zahlungsbezogenen Entitäten, die mit dem Schadenfall verknüpft sind, häufig in einer Transaktions- oder Schecktabelle. Beispiele 4500.00125000.00500.00 | |||
| Zieltermin für die Schadenregulierung ResolutionTargetDate | Das Datum, bis zu dem der Schadenfall gemäß internen oder regulatorischen SLAs voraussichtlich abgeschlossen wird. | ||
| Beschreibung Der Zieltermin für die Schadenregulierung ist die Frist für den Abschluss eines Schadenfalls. Er richtet sich häufig nach Faktoren wie Gerichtsstand, Schadenart und Versicherungsbedingungen. Der Termin dient als Maßstab für die Leistungs- und Compliance-Messung. Dieses Attribut ist wichtig für Dashboards und KPIs zur SLA-Einhaltung. Durch den Vergleich des tatsächlichen Datums der Aktivität „Schaden abgeschlossen“ mit dem Zieltermin kann die Analyse verspätete Schadenfälle automatisch kennzeichnen, die fristgerechte Bearbeitung messen und aufzeigen, welche Schadenarten oder Abteilungen ihre Ziele nicht erreichen. Warum das wichtig ist Dient als Maßstab für die Einhaltung von Service Level Agreements (SLAs) und hilft, Schadenfälle zu erkennen, bei denen eine Verspätung droht. Woher beziehen Dies kann ein benutzerdefiniertes Feld sein oder anhand der in ClaimCenter konfigurierten Geschäftsregeln abgeleitet werden, möglicherweise auf Grundlage bestimmter Schadenkennzahlen. Beispiele 2023-06-142023-07-202023-08-28 | |||
| Zuständiger Gerichtsstand JurisdictionState | Der Bundesstaat oder Gerichtsstand, dessen Vorschriften für den Schadenfall gelten. | ||
| Beschreibung Dieses Attribut gibt den rechtlichen Gerichtsstand an, zum Beispiel den US-Bundesstaat, in dem der Schadenfall bearbeitet wird. Die Versicherungsvorschriften können sich je nach Gerichtsstand erheblich unterscheiden und sich auf erforderliche Prozessschritte, Fristen für Mitteilungen und Dokumentationspflichten auswirken. Für die Compliance-Überwachung ist dieses Attribut unverzichtbar. Die Analyse nach Gerichtsstand zeigt, ob die jeweiligen regionalen Vorschriften eingehalten werden. Sie kann außerdem Unterschiede bei Zykluszeiten oder Prozessabläufen erklären, die auf rechtliche Vorgaben und nicht auf betriebliche Ineffizienz zurückzuführen sind. Warum das wichtig ist Wichtig für die Compliance-Analyse, da je nach Gerichtsstand unterschiedliche Vorschriften für die Schadenbearbeitung gelten. Woher beziehen Ein Standardfeld der Entität Claim, das in der Regel „JurisdictionState“ heißt. Beispiele CANYTXFL | |||
Aktivitäten der Schadenbearbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Erste Rückstellung festgelegt | Kennzeichnet die Anlage der ersten Rückstellungstransaktion für eine Schadenposition, mit der die potenziellen Kosten des Schadenfalls geschätzt werden. Dieses wichtige finanzielle Ereignis wird ausdrücklich erfasst. | ||
| Warum das wichtig ist Dieser Meilenstein ist wichtig für die Finanzanalyse und zeigt, wie schnell eine potenzielle Haftung bewertet wird. Verzögerungen können sich auf Finanzplanung und Berichterstattung auswirken. Woher beziehen Dieses Ereignis wird bei der Anlage des ersten cc_reserveline-Datensatzes erfasst, der einer Schadenposition des Schadenfalls zugeordnet ist. Der CreateTime-Wert der Transaktion ist der Ereignis-Timestamp. Erfassung Ermitteln Sie den frühesten Erstellungs-Timestamp aller Rückstellungspositionen für die Schadenpositionen eines Schadenfalls. Ereignistyp explicit | |||
| Schadenfall abgelehnt | Bezeichnet die endgültige Entscheidung, einen Schadenfall abzulehnen, und bildet damit den Endpunkt des Prozesses. Das Ereignis wird anhand des Statuswechsels des Schadenfalls in einen geschlossenen Status mit dem Ablehnungsgrund "Abgelehnt" abgeleitet. | ||
| Warum das wichtig ist Dies ist ein wichtiges Ergebnisereignis. Die Analyse der Häufigkeit, Gründe und Prozesspfade, die zu Ablehnungen führen, hilft, Probleme bei der Schadenaufnahme, Untersuchung oder Auslegung der Police zu erkennen. Woher beziehen Abgeleitet aus einer Änderung des State-Felds in der Tabelle cc_claim zu "Geschlossen" in Verbindung mit dem Wert "Abgelehnt" oder einem ähnlichen Wert im Feld CloseReason. Der Ereignis-Timestamp ist das CloseDate. Erfassung Filtern Sie nach Statusänderungen von Schadenfällen zu "Geschlossen", bei denen der Grundcode auf eine Ablehnung hinweist. Ereignistyp inferred | |||
| Schadenfall abgeschlossen | Kennzeichnet den erfolgreichen Abschluss eines Schadenfalls, nachdem alle Aktivitäten und Zahlungen abgeschlossen sind. Dieses primäre erfolgreiche End-Event wird anhand einer Änderung des Hauptstatus des Schadenfalls abgeleitet. | ||
| Warum das wichtig ist Als primäres End-Event ist diese Aktivität entscheidend für die Berechnung der Zykluszeit von Anfang bis Ende und die Messung der SLA-Einhaltung. Sie kennzeichnet den Abschluss des Lebenszyklus eines Schadenfalls. Woher beziehen Abgeleitet aus einer Änderung des State-Felds in der Tabelle cc_claim zu "Geschlossen". Der Ereignis-Timestamp ist das CloseDate im Schadenfalldatensatz. Erfassung Ermitteln Sie, wann das Hauptstatusfeld des Schadenfalls auf "Geschlossen" gesetzt wird. Ereignistyp inferred | |||
| Schadenfall angelegt | Diese Aktivität kennzeichnet die erste Schadenmeldung (First Notice of Loss, FNOL) und die offizielle Anlage eines neuen Schadenfalls in Guidewire ClaimCenter. Sie wird ausdrücklich erfasst, wenn eine neue Claim-Entität zum ersten Mal in der Datenbank gespeichert wird. | ||
| Warum das wichtig ist Als primäres Start-Event ist diese Aktivität entscheidend für die Messung der Zykluszeit eines Schadenfalls von Anfang bis Ende. Sie bildet die Grundlage für alle nachfolgenden Leistungs- und Zeit-KPIs. Woher beziehen Dieses explizite Ereignis wird anhand des CreateTime-Felds der Tabelle cc_claim erfasst. Der Auslöser ist die Anlage eines neuen Datensatzes mit einer eindeutigen Claim-ID. Erfassung Ermitteln Sie den Erstellungs-Timestamp des neuen Datensatzes in der Basistabelle der Claim-Entität. Ereignistyp explicit | |||
| Schadenposition angelegt | Diese Aktivität kennzeichnet die Anlage einer Schadenposition (Exposure), die eine bestimmte potenzielle Haftung oder Schadenart im Rahmen des Schadenfalls darstellt, zum Beispiel einen Fahrzeugschaden oder eine Verletzung. In Guidewire wird dieses Ereignis ausdrücklich erfasst. | ||
| Warum das wichtig ist Schadenpositionen sind grundlegend für die Segmentierung und Analyse von Schadenfällen. Wenn Sie ihre Anlage nachverfolgen, können Sie Prozessvarianten nach Komplexität des Schadenfalls und Schadenart besser verstehen. Woher beziehen Erfasst anhand des CreateTime-Felds eines neuen Datensatzes in der Tabelle cc_exposure. Jeder Datensatz ist mit genau einer Claim-ID verknüpft. Erfassung Ermitteln Sie den Erstellungs-Timestamp eines neuen Datensatzes in der Tabelle der Exposure-Entität. Ereignistyp explicit | |||
| Zahlung angewiesen | Diese Aktivität markiert den letzten Schritt des Zahlungsvorgangs: Die Zahlung wird offiziell angewiesen und an das Finanzsystem übermittelt. Es handelt sich um eine ausdrücklich protokollierte Finanztransaktion. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um die Effizienz der Zahlungsabwicklung zu messen. Sie hilft dabei, Verzögerungen bei der Freigabe von Verzögerungen bei der tatsächlichen Auszahlung zu unterscheiden. Woher beziehen Erfasst anhand des IssueDate-Felds oder einer Statusänderung zu "Angewiesen" oder "Übermittelt" in der cc_check- oder cc_transaction-Entität. Häufig handelt es sich um ein ausdrücklich erfasstes Ereignis mit Timestamp. Erfassung Ermitteln Sie das IssueDate-Feld oder den Timestamp der Statusänderung zu "Angewiesen" im Zahlungsdatensatz. Ereignistyp explicit | |||
| Zahlung genehmigt | Bezeichnet die formelle Genehmigung einer Regulierungszahlung. Dieses wichtige Audit-Ereignis wird ausdrücklich erfasst, wenn ein dazu berechtigter Benutzer die Transaktion genehmigt. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein gibt den letzten Zahlungsschritt frei. Die Analyse der Zeit vor und nach dieser Aktivität hilft, Verzögerungen durch Freigabe-Workflows oder die Verfügbarkeit von Führungskräften einzugrenzen. Woher beziehen Dieses Ereignis wird häufig ausdrücklich in der Tabelle cc_history protokolliert. Es bezieht sich auf eine cc_check- oder cc_transaction-Entität und erfasst die Statusänderung von "Freigabe ausstehend" zu "Genehmigt". Erfassung Verfolgen Sie bei einer bestimmten Zahlungstransaktion die Statusänderung zu "Genehmigt". Ereignistyp explicit | |||
| Haftungsentscheidung getroffen | Kennzeichnet den Zeitpunkt, zu dem die Haftungs- oder Verschuldensfrage für eine Schadenposition geklärt wurde. Dieses Ereignis wird üblicherweise anhand einer Statusänderung der Exposure-Entität abgeleitet. | ||
| Warum das wichtig ist Dieser wichtige Entscheidungsmeilenstein ist Voraussetzung für die Phasen der Regulierung und Zahlung. Die Analyse der Zeit bis zu dieser Entscheidung hilft, Engpässe bei der Untersuchung und Bewertung zu erkennen. Woher beziehen Abgeleitet aus der Tabelle cc_history durch die Nachverfolgung einer Änderung des State-Felds oder eines benutzerdefinierten Haftungsstatusfelds der Entität cc_exposure. Der Timestamp des Verlaufsdatensatzes gibt den Ereigniszeitpunkt an. Erfassung Überwachen Sie Audit-Logs oder Verlaufstabellen auf Änderungen am Status oder Haftungsstatus der Schadenposition. Ereignistyp inferred | |||
| Regulierungsbetrag berechnet | Diese Aktivität kennzeichnet den Zeitpunkt, zu dem ein Regulierungsbetrag festgelegt, aber noch nicht zur Zahlung freigegeben wurde. Sie lässt sich anhand der Anlage einer Zahlung mit dem Status "Freigabe ausstehend" ableiten. | ||
| Warum das wichtig ist Kennzeichnet den Übergang von der Bewertung zur Zahlung. Hier beginnt die Messung der KPI "Vorlaufzeit für die Zahlungsfreigabe", die Verzögerungen in der Freigabekette sichtbar macht. Woher beziehen Abgeleitet aus dem CreateTime-Wert eines cc_check- oder cc_transaction-Datensatzes, dessen anfänglicher Status "Freigabe ausstehend" oder ein ähnlicher Status vor "Genehmigt" ist. Erfassung Ermitteln Sie die Anlage eines Zahlungs- oder Transaktionsdatensatzes mit einem Status vor der Freigabe. Ereignistyp inferred | |||
| Schadenfall wiedereröffnet | Bezeichnet den Wechsel eines Schadenfalls vom Status "Geschlossen" zurück zu "Offen", damit weitere Arbeiten ausgeführt werden können. Dieses Ereignis wird anhand einer bestimmten Abfolge von Statusänderungen abgeleitet. | ||
| Warum das wichtig ist Diese Aktivität kennzeichnet Nacharbeit. Eine hohe Zahl wiedereröffneter Schadenfälle weist auf Probleme bei der ursprünglichen Regulierung, übersehene Schäden oder andere Prozessfehler hin. Das führt zu höheren Kosten und geringerer Effizienz. Woher beziehen Abgeleitet aus der Tabelle cc_history durch Ermittlung einer Änderung des State-Felds der cc_claim-Entität von "Geschlossen" zurück zu "Offen" oder einem anderen aktiven Status. Erfassung Überwachen Sie das Hauptstatusfeld des Schadenfalls auf einen Wechsel von einem geschlossenen zu einem offenen Status. Ereignistyp inferred | |||
| Schadenfall zugewiesen | Bezeichnet die Zuweisung eines Schadenfalls an einen bestimmten Benutzer (Schadenregulierer) oder eine Gruppe zur Bearbeitung. Dies wird üblicherweise durch die Überwachung von Änderungen an den Zuweisungsfeldern der Claim-Entität abgeleitet. | ||
| Warum das wichtig ist Die Nachverfolgung von Zuweisungen ist entscheidend, um die Arbeitslast der Schadenregulierer zu analysieren, Engpässe bei der Weiterleitung zu erkennen und die Zeit bis zur ersten Aktion durch die zuständige Person zu messen. Woher beziehen Abgeleitet aus der Tabelle cc_history durch die Nachverfolgung von Änderungen an den Feldern AssignedUser oder AssignedGroup, die einer bestimmten Claim-ID zugeordnet sind. Der Timestamp der Änderung zeigt an, wann das Ereignis eingetreten ist. Erfassung Überwachen Sie Audit-Logs oder Verlaufstabellen auf Änderungen an den Zuweisungsfeldern des Schadenfalls. Ereignistyp inferred | |||
| Untersuchung begonnen | Kennzeichnet den offiziellen Beginn der Untersuchungsphase für einen Schadenfall oder eine Schadenposition. Häufig wird dieses Ereignis anhand der Anlage der ersten untersuchungsbezogenen "Aktivität" (Aufgabe) in Guidewire abgeleitet. | ||
| Warum das wichtig ist Diese Aktivität markiert den Beginn einer wichtigen, oft langwierigen Phase. Die Analyse der Zeit bis zum Untersuchungsbeginn und der Dauer der Untersuchung selbst macht wesentliche Engpässe sichtbar. Woher beziehen Abgeleitet aus dem CreateTime-Wert eines cc_activity-Datensatzes, dessen ActivityPattern mit einer Untersuchung zusammenhängt, zum Beispiel "Erstuntersuchung" oder "Zeugen kontaktieren". Erfassung Ermitteln Sie die erste Anlage einer Aufgabe mit einem untersuchungsbezogenen Muster oder Betreff. Ereignistyp inferred | |||
| Zusätzliche Informationen angefordert | Bezeichnet eine Anfrage an den Anspruchsteller oder einen Dritten nach weiteren Informationen oder Unterlagen. Üblicherweise wird dies als ausdrücklich angelegte "Aktivität" (Aufgabe) in ClaimCenter erfasst. | ||
| Warum das wichtig ist Diese Aktivität ist der Ausgangspunkt für die Messung der KPI "Zykluszeit für das Einholen zusätzlicher Informationen". Häufige Anfragen können auf unvollständige FNOL-Prozesse oder ineffiziente Informationsbeschaffung hindeuten. Woher beziehen Erfasst anhand des CreateTime-Werts eines cc_activity-Datensatzes, dessen ActivityPattern die Anforderung von Unterlagen oder Informationen bei einer externen Partei betrifft. Erfassung Ermitteln Sie die Anlage einer Aufgabe zur Anforderung externer Informationen. Ereignistyp explicit | |||
| Zusätzliche Informationen eingegangen | Kennzeichnet den Abschluss einer Anfrage nach zusätzlichen Informationen. Erfasst wird das Ereignis, wenn die zugehörige "Aktivität" (Aufgabe) zur Informationsanforderung als "Abgeschlossen" markiert wird. | ||
| Warum das wichtig ist Dies ist der Endpunkt für die KPI "Zykluszeit für das Einholen zusätzlicher Informationen". Lange Zeiträume zwischen Anfrage und Eingang sind eine häufige Ursache für Verzögerungen bei der Schadenbearbeitung. Woher beziehen Erfasst anhand des CloseTime-Werts eines cc_activity-Datensatzes, dessen ActivityPattern eine Informationsanfrage betrifft. Der Status der Aktivität muss "Abgeschlossen" sein. Erfassung Ermitteln Sie den Abschluss-Timestamp einer Aufgabe zur Anforderung externer Informationen. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen prüfen: Vergewissern Sie sich, dass Sie über die erforderlichen Berechtigungen und Zugangsdaten für den schreibgeschützten Zugriff auf die Guidewire DataHub-/InfoCenter-Data-Mart-Datenbank verfügen. Stellen Sie sicher, dass die ETL-Jobs zur Befüllung des Schaden-Data-Marts erfolgreich laufen und die Daten aktuell sind.
- Datenbankverbindung herstellen: Stellen Sie mit einem gängigen SQL-Client, etwa DBeaver oder SQL Server Management Studio, eine Verbindung zum Datenbankserver des Data Marts her.
- Schema untersuchen: Machen Sie sich vor der vollständigen Abfrage mit dem Schema des Data Marts vertraut. Ermitteln Sie die zentralen Tabellen für Schäden, Deckungspositionen, Aktivitäten und Finanztransaktionen. Häufig tragen die Tabellen die Suffixe _dim (Dimension) und _fact (Fakt). So können Sie die Platzhalter für Tabellen- und Spaltennamen im bereitgestellten Skript überprüfen.
- SQL-Abfrage vorbereiten: Kopieren Sie das vollständige SQL-Skript aus dem Abfrageabschnitt in den Abfrageeditor Ihres SQL-Clients.
- Platzhalter anpassen: Prüfen Sie das Skript sorgfältig und ersetzen Sie alle Platzhalterwerte. Dazu gehören der Datenbank- oder Schemaname (z. B. [YourDataMart]), der Datumsbereich ('[StartDate]', '[EndDate]') und systemspezifische Konfigurationswerte wie Aktivitätsmuster und Statuscodes.
- Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage für den Data Mart aus. Die Ausführungszeit hängt vom gewählten Datumsbereich und Datenvolumen Ihres Systems ab.
- Erste Datenprüfung: Prüfen Sie nach Abschluss der Abfrage die ersten hundert Ergebniszeilen. Kontrollieren Sie, ob ClaimID, ActivityName und EventTime wie erwartet befüllt sind und verschiedene Aktivitätstypen enthalten sind.
- Als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie einen aussagekräftigen Dateinamen, zum Beispiel guidewire_claimcenter_event_log.csv.
- Für ProcessMind formatieren: Speichern Sie die CSV-Datei mit UTF-8-Kodierung. Prüfen Sie, ob die Kopfzeile den Spaltenaliasen der SQL-Abfrage entspricht. Anschließend können Sie die Datei in ProcessMind hochladen.
Konfiguration
- Datenquelle: Guidewire DataHub/InfoCenter Claims Data Mart. Dabei handelt es sich um eine voraggregierte, dimensionale Datenbank für Berichte und Analysen, die von der produktiven ClaimCenter-Datenbank getrennt ist.
- Erforderliche Berechtigungen: Schreibgeschützter Zugriff auf die SQL-Datenbank des Data Marts. Sie benötigen einen Benutzernamen, ein Passwort und die Verbindungsdaten (Serveradresse und Datenbankname).
- Status der ETL-Jobs: Die Genauigkeit des Exports hängt davon ab, dass die Guidewire-ETL-Jobs zur Befüllung des Data Marts erfolgreich und rechtzeitig ausgeführt werden. Prüfen Sie den Zeitpunkt des letzten erfolgreichen Laufs, um die Aktualität der Daten einzuschätzen.
- Datumsbereich filtern: Die Abfrage enthält WHERE-Klauseln mit den Platzhaltern '[StartDate]' und '[EndDate]'. Beginnen Sie am besten mit einem begrenzten Zeitraum von 3 bis 6 Monaten, um die Leistung zu steuern. Der Datumsfilter wird auf CreateTime des Schadens angewendet.
- Konfigurationsabhängige Werte: Guidewire lässt sich umfassend konfigurieren. Passen Sie die Werte in den WHERE-Klauseln an die Einrichtung Ihrer Organisation an. Dazu gehören:
- ActivityPattern-Namen (z. B. 'fnol', 'investigation', 'Request additional information')
- ClaimStatus-, ExposureStatus- und CloseReason-Codes (z. B. 'denied', 'closed')
- TransactionStatus-Codes (z. B. 'pendingapproval', 'approved', 'issued')
- Leistung: Abfragen großer Verlaufs- oder Audit-Tabellen können viele Ressourcen beanspruchen. Bei sehr großen Datenmengen empfiehlt sich die Ausführung außerhalb der Spitzenzeiten. Stellen Sie sicher, dass die Spalten ClaimID oder ClaimNumber in den relevanten Tabellen indiziert sind.
a Beispielabfrage 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'; Schritte
- Vergewissern Sie sich, dass Ihre Organisation eine aktive Snowflake-Datenfreigabe für Guidewire Cloud Data Access (CDA) für die ClaimCenter-Umgebung hat. Lassen Sie sich von Ihrer Guidewire-Cloud-Administration die Snowflake-Konto-ID, Datenbank, Schema, Warehouse, Rolle, Authentifizierungsmethode und zulässige Netzwerkkonfiguration geben.
- Prüfen Sie genau, welche CDA-Datenbankobjekte und Spalten in der Freigabe verfügbar sind. CDA-Schemas und Spaltennamen können je nach Mandant, Release, Konfiguration und Datenfreigabemodell variieren. Ersetzen Sie jeden Platzhalter in eckigen Klammern durch das entsprechende Objekt aus Ihrer Umgebung. Gehen Sie nicht davon aus, dass operative ClaimCenter-Entitätsnamen in Snowflake unverändert verfügbar sind.
- Ermitteln Sie die Datenquellen für Schadenanlage, Schaden-Zuweisungsverlauf, Anlage von Deckungspositionen, Rückstellungstransaktionen, Aktivitäten, Statusverlauf von Deckungspositionen, Zahlungsstatusverlauf und Schadenstatusverlauf. Falls Ihre Freigabe keine Verlaufstabellen oder Audit-Datensätze enthält, richten Sie eine freigegebene Quelle ein, die für jeden erforderlichen Statuswechsel den vorherigen und neuen Wert, den Ereigniszeitpunkt und den Benutzer speichert.
- Stellen Sie über einen autorisierten Snowflake-Client, ein Worksheet, Notebook oder SQL-Ausführungstool eine Verbindung zur CDA-Snowflake-Freigabe her. Verwenden Sie nach Möglichkeit eine schreibgeschützte Rolle. Legen Sie in der Abfrage mit [Start timestamp] und [End timestamp] den Beginn und das Ende des Analysezeitraums fest. Wenden Sie mit [Company filter] gegebenenfalls einen freigegebenen Unternehmens- oder Geschäftseinheitenfilter an.
- Ersetzen Sie die Platzhalter für Datenquellen in der Abfrage durch geprüfte CDA-Objekt- und Spaltennamen. Die Abfrage erzeugt ausdrücklich Zeilen für alle 14 erforderlichen Aktivitäten: 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 und Claim Reopened.
- Führen Sie die Abfrage aus und prüfen Sie das Ergebnisschema. Die Ausgabe muss ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus und LossCause enthalten. Für ProcessMind sind ClaimID, ActivityName und EventTime erforderlich. Bewahren Sie eine Zeile pro Ereignis und fassen Sie Ereignisse nicht nach Schaden zusammen.
- Prüfen Sie vor dem Export Zeitstempel, Statuswechsel, Zuweisungsänderungen, Duplikate und Aktivitätszahlen. Stellen Sie sicher, dass die Ereigniszeitstempel dieselbe Zeitzone verwenden. Mehrere Ereignisse mit identischem Zeitstempel müssen als separate Zeilen erhalten bleiben, wenn sie unterschiedliche Geschäftsaktivitäten darstellen.
- Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei oder in einem anderen von ProcessMind unterstützten Tabellenformat. Ordnen Sie ClaimID der Case-ID, ActivityName der Aktivität und EventTime dem Ereigniszeitstempel zu. Fügen Sie die empfohlenen Attribute als zusätzliche Ereignisattribute hinzu und laden Sie die Datei in ProcessMind hoch. Ergänzen Sie keine Aktivitäten, die nicht aus diesem Export hervorgehen.
Konfiguration
- Verbindung und Berechtigungen: Verwenden Sie die von Guidewire bereitgestellte Snowflake-Datenfreigabe über ein autorisiertes Snowflake-Konto, eine autorisierte Rolle und ein autorisiertes Warehouse sowie einen zulässigen Netzwerkpfad. Aus Sicht des Datenempfängers ist CDA schreibgeschützt. Die erforderlichen Zugriffsrechte hängen von Ihrer Mandantenkonfiguration ab und können Abfrageberechtigungen für die freigegebene Datenbank sowie bestimmte Schemas oder Views umfassen.
- Konfiguration der Quelldaten: Ersetzen Sie alle Quellenverweise in eckigen Klammern durch Objekte, die in Ihrer CDA-Freigabe überprüft wurden. Die Abfrage legt bewusst keine allgemeingültigen ClaimCenter-Tabellen- oder Spaltennamen fest, da die verfügbaren CDA-Strukturen je nach Release und Mandant variieren.
- Datumsbereich: Beginnen Sie für die Validierung und operative Analyse mit einem Zeitraum von drei bis sechs Monaten. Verwenden Sie erst dann einen längeren Zeitraum, wenn Sie die Warehouse-Kapazität, die Aufbewahrungsdauer der Ereignisdaten und eine akzeptable Abfragedauer geprüft haben. Filtern Sie Quelldatensätze nach dem jeweiligen Ereigniszeitstempel, nicht nur nach dem Erstellungsdatum des Schadens, damit spätere Aktivitäten nicht ausgeschlossen werden.
- Erforderliche Ausgabe: ClaimID, ActivityName und EventTime müssen für jede Ereigniszeile vorhanden und dürfen nicht leer sein. ActivityName muss exakt die Bezeichnungen verwenden, die das ProcessMind-Prozessmodell erwartet.
- Empfohlene Ausgabe: Nehmen Sie AssignedAdjuster, ClaimType, ClaimStatus und LossCause auf. Wenn verfügbar, sollten diese Werte dem Snapshot zum Ereigniszeitpunkt entnommen werden. Sind nur aktuelle Werte verfügbar, dokumentieren Sie diese Einschränkung, da historische Attribute dann möglicherweise nicht den damaligen Stand wiedergeben.
- Filter: Wenden Sie [Company filter] erst an, nachdem Sie die entsprechende mandantenspezifische Spalte für Unternehmen, Organisation, Geschäftseinheit oder juristische Person ermittelt haben. Filtern Sie nicht nach Dokumenttyp, es sei denn, die ClaimCenter-Konfiguration enthält ein geprüftes Feld für den Dokumenttyp, das für die angeforderten Aktivitäten relevant ist.
- Ereignisverlauf: Für Zuweisungen, Untersuchungen, Informationsanfragen, Haftungsentscheidungen, Zahlungsstatus und wiedereröffnete Schäden sind Verlaufs- oder Audit-Daten erforderlich, um Statuswechsel zu ermitteln. Aus Tabellen mit ausschließlich aktuellen Statuswerten lassen sich frühere Ereignisse nicht zuverlässig rekonstruieren.
- Deduplizierung: Verwenden Sie nach Möglichkeit eine geprüfte Quellereignis-ID. Die Abfrage nutzt ROW_NUMBER lediglich als konfigurierbare Absicherung. Deduplizieren Sie Ereignisse nicht allein anhand von ClaimID und Zeitstempel, wenn unterschiedliche Aktivitäten berechtigterweise gleichzeitig stattfinden können.
- Leistung: Begrenzen Sie den Datumsbereich, wählen Sie nur erforderliche Spalten aus, filtern Sie jede Quelle nach ihrem Ereigniszeitstempel und verwenden Sie ein passend dimensioniertes Snowflake-Warehouse. Bei großen Datenmengen empfiehlt sich eine geprüfte Ereignis-View oder ein inkrementeller Export.
- Zeitzone: Vereinheitlichen Sie EventTime auf eine dokumentierte Zeitzone. Prüfen Sie vor dem Laden des Event Logs, ob CDA-Zeitstempel als UTC, Ortszeit oder in unterschiedlichen Snowflake-Zeitstempelformaten gespeichert sind.
- Voraussetzungen: Prüfen Sie, ob die Freigabe die erforderlichen ClaimCenter-Daten zu Finanzen, Aktivitäten, Zuweisungen, Deckungspositionen, Zahlungen und Statusverläufen enthält und ob die Aufbewahrungsrichtlinien die benötigten historischen Statuswechsel abdecken.
a Beispielabfrage 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; Schritte
- Vergewissern Sie sich, dass der direkte Lesezugriff auf die lokale operative Guidewire-ClaimCenter-Datenbank genehmigt ist, die Datenbankplattform und Schemaversion dokumentiert sind und eine schreibgeschützte Verbindung zur Verfügung steht. Fragen Sie die Produktionsdatenbank nur innerhalb eines genehmigten Exportzeitraums ab.
- Ermitteln Sie die physischen Tabellen und Spalten Ihrer ClaimCenter-Implementierung. Ordnen Sie die Entitäten für Schäden, Deckungspositionen, Aktivitäten, Zuweisungen, Rückstellungen, Zahlungen, Statusverläufe und Benutzer oder Gruppen den Platzhaltern in der Abfrage zu. Da physische Namen und Audit-Strukturen je nach Implementierung und Version variieren, ersetzen Sie Platzhalter erst, nachdem Sie sie anhand des Datenbankkatalogs und des ClaimCenter-Datenmodells geprüft haben.
- Legen Sie den Exportzeitraum mit [Start date parameter] und [End date parameter] fest. Verwenden Sie ein rollierendes Überlappungsfenster, etwa ein oder zwei Tage vor dem gewünschten Startdatum, wenn Statusänderungen, Aufgabenabschlüsse oder Finanztransaktionen außerhalb des primären Zeitraums der Schadenanlage erfasst werden können.
- Führen Sie die vollständige SQL-Anweisung mit schreibgeschützten Berechtigungen aus. Jede Aktivität wird als explizite Ereigniszeile ausgegeben. Die Abfrage setzt nicht voraus, dass ProcessMind nach dem Laden Ereignisse ableitet. Ereignisse, die aus Feldänderungen abgeleitet werden, ermittelt die SQL-Anweisung anhand der entsprechenden Verlaufs- oder Audit-Datensätze.
- Prüfen Sie die Quellzuordnungen für jede Aktivität. Stellen Sie sicher, dass die Schadenanlage den ersten gespeicherten Claim-Datensatz verwendet, Zuweisungen anhand von Zuweisungsänderungen ermittelt werden, die Anlage von Deckungspositionen auf deren Erstellungsdatensätzen beruht und die erste Rückstellungstransaktion je Deckungsposition verwendet wird. Für Untersuchungen und Informationsanfragen sind Aktivitätsdatensätze heranzuziehen, für Haftungsentscheidungen der konfigurierte Statuswechsel der Deckungsposition, für die Berechnung der Regulierung eine Zahlung im Status „Genehmigung ausstehend“ sowie für Zahlungsfreigabe und -ausstellung die entsprechenden Finanz-Audit-Status.
- Bringen Sie die Ausgabe in das erforderliche Event-Log-Format. ClaimID muss als Case-ID dienen, ActivityName muss genau einen der vierzehn dokumentierten Aktivitätsnamen enthalten und EventTime muss ein Zeitstempel sein. Übernehmen Sie die empfohlenen Attribute, darunter AssignedAdjuster, ClaimType, ClaimStatus und LossCause, sofern die Quelldatenzuordnung dies ermöglicht.
- Prüfen Sie doppelte Ereignisse und deren Reihenfolge. Enthält die Quelle mehrere Audit-Zeilen für denselben Geschäftsvorgang, wenden Sie in der entsprechenden Common Table Expression den implementierungsspezifischen Deduplizierungsschlüssel an. Fassen Sie keine unterschiedlichen Geschäftsvorgänge zusammen, wenn sie verschiedene Zeitstempel oder Quell-IDs haben.
- Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei oder in einem anderen von ProcessMind unterstützten Tabellenformat. Fügen Sie eine Kopfzeile mit ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus und LossCause ein. Zeitstempel müssen Zeitzoneninformationen enthalten oder durchgehend der dokumentierten Datenbankzeitzone entsprechen. Laden Sie die Datei in ProcessMind hoch und ordnen Sie ClaimID der Case-ID, ActivityName der Aktivität und EventTime dem Ereigniszeitstempel zu.
Konfiguration
- Datenbankzugriff: Verwenden Sie ein schreibgeschütztes Konto mit Berechtigung für die erforderlichen operativen ClaimCenter-Tabellen, Verlaufstabellen, Aktivitätstabellen und Finanztransaktionstabellen. Für den Export sind keine Schreib-, Schemaänderungs- oder Administrationsrechte erforderlich.
- Schemazuordnung: Ersetzen Sie [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] und die zugehörigen Platzhalter durch Namen, die in der Zielimplementierung geprüft wurden. Gehen Sie nicht davon aus, dass der logische Name einer Guidewire-Entität dem Namen der physischen Datenbanktabelle entspricht.
- Datumsbereich: Beginnen Sie mit Daten aus drei bis sechs Monaten. Verwenden Sie [Start date parameter] und [End date parameter] und berücksichtigen Sie ein Überlappungsfenster, wenn Ereignisse nach der Schadenanlage erfasst werden können oder wiedereröffnete Schäden mehrere Berichtszeiträume umfassen.
- Filter: Wenden Sie Filter für [Company Code filter], [Document Type filter], Zuständigkeit, Geschäftsbereich oder andere organisationsspezifische Kriterien erst an, nachdem Sie die physischen Spalten und ihre fachliche Bedeutung geprüft haben. Schließen Sie Schäden ohne Zahlung oder Deckungsposition nicht aus, da diese Datensätze für eine vollständige Lebenszyklusanalyse erforderlich sind.
- Aktivitätsnamen: Verwenden Sie die vierzehn ActivityName-Werte exakt wie in der Abfrage definiert, damit ProcessMind einheitliche Ereignisbezeichnungen erhält.
- Ereignisbedeutung: Als abgeleitet gekennzeichnete Aktivitäten werden in SQL anhand von Status-, Zuweisungs-, Verlaufs- oder Aktivitätsänderungen erzeugt. ProcessMind leitet diese Ereignisse nach dem Laden nicht aus anderen Zeilen ab.
- Leistung: Begrenzen Sie den Exportzeitraum, wählen Sie nur erforderliche Spalten aus, filtern Sie Quelltabellen vor Verknüpfungen und prüfen Sie Indizes für Schaden-IDs, Deckungspositions-IDs, Ereigniszeitstempel, Statusfelder und Transaktions-IDs. Führen Sie große Exporte nach Möglichkeit über eine Reporting-Replik aus.
- Konsistenz: Verwenden Sie eine für Berichte geeignete Transaktionsisolationsstufe und legen Sie einen konsistenten Exportzeitpunkt fest. Lesen Sie keine Tabellen aus, während ein Finanzlauf oder eine umfangreiche Statusänderung nur teilweise abgeschlossen ist.
- Zeitzonen: Dokumentieren Sie die Datenbankzeitzone und konvertieren Sie alle Quellzeitstempel vor dem Export in eine vereinbarte Zeitzone. Mischen Sie keine lokalen Anwendungszeitstempel mit Zeitstempeln des Datenbankservers.
- Voraussetzungen: Prüfen Sie, ob die erforderlichen ClaimCenter-Module, Finanzberechtigungen, Audit- oder Verlaufsdaten und Datenbankverbindungen verfügbar sind. Wenn Verlaufs- oder Audit-Daten nicht aufbewahrt werden, lassen sich die entsprechenden abgeleiteten Aktivitäten nicht zuverlässig rekonstruieren.
- Validierungskonfiguration: Dokumentieren Sie für jeden Export die ClaimCenter-Version, Datenbankplattform, Schemazuordnung, den Exportzeitpunkt, Datumsparameter, Filter und Zeilenanzahlen.
a Beispielabfrage 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; Möchten Sie loslegen?
Bereiten Sie Ihre Daten mit diesem Template für die Analyse vor und gewinnen Sie Erkenntnisse zu Ihrer Schadenbearbeitung. Beginnen Sie noch heute damit, Ihre Workflows zu verbessern.
Schadenbearbeitung beschleunigen und Fälle schneller abschließen
Bauen Sie Rückstände ab, beugen Sie Betrug vor und streben Sie eine durchgängige Verarbeitung von 70 % an.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.