Datenvorlage: Schadenbearbeitung
Ihr Data Template für die Schadenbearbeitung
- Empfohlene Attribute zur Erfassung
- Wichtige zu verfolgende Aktivitäten
- Extraktionsleitfaden für Guidewire ClaimCenter
Attribute der Schadenbearbeitung
| Name | Beschreibung | ||
|---|---|---|---|
Aktivitätsname ActivityName | Bezeichnung der Geschäftstätigkeit oder des Ereignisses zu einem bestimmten Zeitpunkt im Lebenszyklus des Claims. | ||
Beschreibung Dieses Attribut beschreibt einen konkreten Schritt oder Meilenstein im Schadenprozess, z. B. 'Claim Created', 'Investigation Started' oder 'Payment Issued'. Die Abfolge dieser Aktivitäten für eine bestimmte Claim-ID bildet den Prozessfluss. Die Analyse von Reihenfolge, Häufigkeit und Zeitabständen zwischen Aktivitäten ist der Kern von Process Mining. So lassen sich Prozessmodelle entdecken, Engpässe identifizieren, Nacharbeitsschleifen erkennen und Prozessabweichungen analysieren. Warum es wichtig ist Es definiert die Schritte des Prozesses und ermöglicht die Visualisierung von Prozesslandkarten sowie die Analyse von Prozessfluss und Engpässen. Woher erhalten Dies wird üblicherweise aus Event-Tabellen oder Audit-Logs in ClaimCenter abgeleitet, oft indem bestimmte Systemereignisse oder Statuswechsel auf standardisierte Aktivitätsnamen abgebildet werden. Beispiele Schadenfall angelegtHaftungsentscheidung getroffenZahlung angewiesenSchadenfall geschlossen | |||
Ereigniszeit EventTime | Das genaue Datum und die genaue Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
Beschreibung Dieser Zeitstempel markiert den exakten Zeitpunkt, zu dem eine Aktivität im System erfasst wurde. Er ist die Grundlage für jede zeitbasierte Prozessanalyse. Die chronologische Sortierung der EventTime für eine einzelne Claim ID ermöglicht die Rekonstruktion des Prozessflusses. Die Zeitdifferenz zwischen aufeinanderfolgenden Events wird genutzt, um Durchlauf-, Warte- und Bearbeitungszeiten zu berechnen – kritisch für Performanceanalysen, Engpassidentifikation und SLA-Monitoring. Warum es wichtig ist Dieser Zeitstempel ist essenziell, um Events zu ordnen, Durchlauf- und Dauerzeiten zu berechnen und Verzögerungen im Prozess zu erkennen. Woher erhalten Zu finden neben event- oder Aktivitätsdaten in den History- bzw. Audit-Tabellen von Guidewire ClaimCenter, oft als Feld 'CreateTime' oder 'UpdateTime'. Beispiele 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
Schadenfall-ID ClaimID | Die eindeutige Kennung jedes Claims, die als primäre Case-ID dient. | ||
Beschreibung Die Claim-ID ist das Fundament der Analyse in der Schadenbearbeitung. Sie identifiziert jeden Fall eindeutig – von der Meldung bis zum Abschluss – und verknüpft alle zugehörigen Aktivitäten, Dokumente, Zahlungen und Kommunikation. So entsteht ein vollständiges, konsistentes Bild über den gesamten Lebenszyklus des Claims. Im Process Mining ist jedes Event im Datensatz einer Claim-ID zugeordnet. Dadurch lässt sich der End-to-End-Prozess rekonstruieren – unerlässlich für die Analyse von Durchlaufzeiten, die Erkennung von Prozessvarianten und das Tracking des Claims über verschiedene Abteilungen und Schadenbearbeiter hinweg. Warum es wichtig ist Er ist der zentrale Schlüssel, der alle zugehörigen Ereignisse verbindet und die vollständige Nachverfolgung und Analyse des Wegs eines einzelnen Schadenfalls ermöglicht. Woher erhalten Dies ist ein Primärschlüssel in Guidewire ClaimCenter, typischerweise als Claim.ClaimNumber oder als ähnliches Feld in der Kernentität 'Claim' zu finden. Beispiele 000-123-45678000-987-65432001-456-11223 | |||
Assigned Adjuster AssignedAdjuster | Name oder ID des Benutzers, dem der Claim oder eine bestimmte Aktivität zugewiesen ist. | ||
Beschreibung Dieses Attribut identifiziert den zuständigen Schadenbearbeiter zu einem bestimmten Zeitpunkt. Ein Bearbeiter kann dem gesamten Schadenfall oder einzelnen Aufgaben darin zugewiesen sein. Die Analyse nach zuständigem Bearbeiter ist entscheidend für die Arbeitslastverteilung, die Leistungssteuerung und die Identifikation von Schulungsbedarf. Sie beantwortet Fragen wie: 'Wer hat den größten Fallbestand?', 'Gibt es Leistungsunterschiede zwischen Bearbeitern?' und 'Ist die Arbeit gleichmäßig verteilt?'. Warum es wichtig ist Erfasst die Nutzerbeteiligung und ermöglicht Auslastungsanalysen, Leistungsvergleiche und das Erkennen ressourcenbedingter Engpässe. Woher erhalten Verfügbar in der Claim‑ oder Exposure‑Entität in ClaimCenter, häufig mit dem User‑Objekt verknüpft (z. B. Claim.Assignee). Beispiele j.doem.smiths.jones | |||
Schadenart ClaimType | Die Kategorie des Schadenfalls, z. B. Kfz, Sach oder Haftpflicht. | ||
Beschreibung Die Schadenart ist die grundlegende Kategorisierung eines Schadenfalls – je nach Sparte oder Art des Schadens. Unterschiedliche Schadenarten folgen oft eigenen Abläufen, haben verschiedene Komplexitätsstufen und unterliegen unterschiedlichen regulatorischen Vorgaben. Eine Segmentierung der Prozessanalyse nach Schadenart ist entscheidend für aussagekräftige Erkenntnisse. So lassen sich die Prozessleistung über die Sparten hinweg vergleichen, artspezifische Engpässe identifizieren und Verbesserungsinitiativen gezielt auf die Besonderheiten jeder Kategorie zuschneiden. Warum es wichtig ist Ermöglicht die Segmentierung von Schäden, da unterschiedliche Typen (z. B. Kfz vs. Sach (Property)) oft unterschiedliche Prozesse und Zielwerte haben. Woher erhalten Abgeleitet aus den Datenobjekten 'Policy' oder 'Claim' in ClaimCenter, häufig auf Basis des Line-of-Business-Codes (LOB). Beispiele Privat-KfzGewerbliche SachversicherungAllgemeine HaftpflichtArbeitsunfallversicherung | |||
Schadenursache LossCause | Der konkrete Grund bzw. die Ursache des Schadensereignisses (z. B. Kollision, Brand, Wasserschaden). | ||
Beschreibung Dieses Attribut beschreibt, warum der Schaden gemeldet wurde. Die Schadensursache bestimmt häufig die nötigen Prüfungsschritte, die einzubindenden Experten und die Komplexität des Falls. Die Analyse nach Schadensursache deckt Muster auf. Beispielsweise können 'Wasserschäden' häufiger Nacharbeit erfordern oder mehr Spezialisten involvieren als Fälle mit 'Diebstahl'. Solche Erkenntnisse helfen, spezialisierte und effizientere Abläufe aufzubauen. Warum es wichtig ist Liefert Kontext zur Art des Schadens und ermöglicht Analysen, wie unterschiedliche Schadenursachen den Prozessfluss und die Dauer beeinflussen. Woher erhalten Dies ist ein Standardfeld der Entität 'Claim', üblicherweise 'LossCause' genannt. Beispiele KollisionFeuerWasserschadenDiebstahl | |||
Status des Schadenfalls ClaimStatus | Der Gesamtstatus des Claims zum Zeitpunkt des Events (z. B. Open, Closed, Denied). | ||
Beschreibung Dieses Attribut spiegelt den übergeordneten Status des Schadenfalls wider. Wichtige Status sind 'Open', 'Closed', 'Denied' und 'Reopened'. Der Endstatus eines Schadenfalls ist eine zentrale Ergebniskennzahl. Die Nachverfolgung von Änderungen am Claim-Status hilft, wesentliche Meilensteine und Ergebnisse zu definieren. So lassen sich der endgültige Ausgang eines Falls bestimmen, Ablehnungsquoten berechnen und die Häufigkeit von Wiedereröffnungen nach Abschluss analysieren – oft ein Hinweis auf Prozessprobleme oder Unzufriedenheit auf Kundenseite. Warum es wichtig ist Kennzeichnet den Ausgang eines Schadenfalls – zentral für die Analyse von Ablehnungsquoten, Schließungsmustern und Wiedereröffnungsraten. Woher erhalten Dies ist ein zentrales Feld der Entität 'Claim', typischerweise 'State' oder 'Status' genannt. Beispiele OffenGeschlossenAbgelehntWiedereröffnet | |||
Abteilung Department | Die Fachabteilung oder Organisationseinheit, die für die Schadenaktivität zuständig ist. | ||
Beschreibung Dieses Attribut gibt die Abteilung bzw. das Team des zugewiesenen Bearbeiters an, z. B. 'Kfz-Schäden', 'Sachschäden' oder 'Special Investigations Unit (SIU)'. Es bietet den organisatorischen Kontext des Prozesses. Die Analyse nach Abteilung ist wichtig, um die Prozessleistung auf Organisationsebene zu verstehen. So lassen sich Übergabeverzögerungen zwischen Teams erkennen, Effizienz vergleichen und Ressourcen in der Schadenorganisation gezielter einsetzen. Warum es wichtig ist Liefert organisatorischen Kontext, ermöglicht Leistungsvergleiche zwischen Teams und macht Übergabeprobleme zwischen Abteilungen sichtbar. Woher erhalten Diese Information ist in der Regel dem Profil des zugewiesenen Nutzers oder der Gruppe in ClaimCenter zugeordnet. Beispiele Auto Claims DivisionSachschadenabteilungSonderermittlungseinheit (SIU) | |||
Bearbeitungszeit ProcessingTime | Die Zeit, in der aktiv an einer Aktivität gearbeitet wurde. | ||
Beschreibung Processing Time misst die Zeit, in der eine Activity aktiv bearbeitet wird – berechnet als Differenz zwischen End Time und Start Time. Im Unterschied zur Durchlaufzeit umfasst sie keine Wartephasen. Diese Kennzahl ist zentral für Performance-Analysen, weil sie den eigentlichen Aufwand von Leerlauf trennt. So erkennen Sie präzise, welche Schritte wirklich zeitintensiv sind und wo sich durch Schulungen, bessere Tools oder Prozessdesign Effizienzgewinne realisieren lassen. Warum es wichtig ist Misst die aktive Bearbeitungszeit einer Activity und hilft, wertschöpfende Zeit von Wartezeit zu unterscheiden. Woher erhalten Berechnetes Feld: EndTime - StartTime. Erfordert, dass beide Zeitstempel in den Quelldaten vorhanden sind. Beispiele PT8HPT15MP2D | |||
Bundesstaat der Gerichtsbarkeit JurisdictionState | Der Rechtsraum (z. B. Bundesland), in dem der Claim geführt wird und der die aufsichtsrechtlichen Anforderungen vorgibt. | ||
Beschreibung Dieses Attribut gibt den Rechtsraum an (z. B. den US-Bundesstaat), in dem der Schadenfall bearbeitet wird. Versicherungsrechtliche Vorgaben unterscheiden sich teils deutlich zwischen Rechtsräumen und beeinflussen notwendige Prozessschritte, Kommunikationsfristen und Dokumentation. Für die Compliance-Überwachung ist dieses Attribut zentral. Die Analyse nach Rechtsraum hilft sicherzustellen, dass spezifische regulatorische Anforderungen eingehalten werden. Sie erklärt zudem Unterschiede in Durchlaufzeiten oder Prozesspfaden, die durch gesetzliche Vorgaben und nicht durch operative Ineffizienzen entstehen. Warum es wichtig ist Für die Compliance-Analyse entscheidend, da unterschiedliche Rechtsordnungen verschiedene Vorgaben haben, die die Schadenbearbeitung beeinflussen. Woher erhalten Ein Standardfeld der Claim‑Entität, typischerweise als 'JurisdictionState' bezeichnet. Beispiele CANYTXFL | |||
Endzeit EndTime | Zeitstempel, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
Beschreibung Die Endzeit markiert den Abschluss einer Aktivität – insbesondere bei Aufgaben mit messbarer Dauer, etwa 'Investigation' oder 'Document Review'. Viele Process-Mining-Aktivitäten sind punktuell (StartTime genügt), Aktivitäten mit klarem Start und Ende werden mit beiden Zeitstempeln präziser abgebildet. Dieses Attribut erlaubt die exakte Berechnung der Bearbeitungszeit einer Aktivität – getrennt von der Wartezeit. So lässt sich erkennen, welche Aufgaben tatsächlich zeitintensiv sind, statt nur lange Pausen zwischen Schritten zu sehen. Warum es wichtig ist Ermöglicht die genaue Messung der Dauer einer Aktivität – mit Trennung von Bearbeitungs- und Wartezeit. Woher erhalten Dies muss gegebenenfalls abgeleitet werden, indem ein nachfolgendes Event gefunden wird, das die Aktivität logisch abschließt (z. B. Statuswechsel von 'In Progress' zu 'Completed'). Beispiele 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Erneute Informationsanforderung RepeatedInfoRequestFlag | Kennzeichen (Flag), ob 'Additional Info Requested' beim selben Schaden mehr als einmal aufgetreten ist. | ||
Beschreibung Dieses boolesche Kennzeichen steht auf true, wenn ein Schadenfall mehr als eine Aktivität 'Additional Info Requested' aufweist. Das deutet oft auf Ineffizienzen in der anfänglichen Informationsbeschaffung hin. Dieses Attribut stützt unmittelbar den KPI 'Quote wiederholter Informationsanfragen'. Es quantifiziert das Problem unvollständiger Erstaufnahme, das zu erheblichen Verzögerungen und Kundenunzufriedenheit führen kann. Die Analyse gekennzeichneter Fälle hilft, Checklisten und Vorgehensweisen für Bearbeiter so zu verbessern, dass alle benötigten Informationen gleich beim ersten Mal angefordert werden. Warum es wichtig ist Erkennt Ineffizienzen, wenn Informationen nicht gleich beim ersten Mal vollständig erhoben werden – mit der Folge von Verzögerungen und Nacharbeit. Woher erhalten Wird im Process‑Mining‑Tool berechnet, indem die Vorkommen der Aktivität 'Additional Info Requested' je Fall gezählt werden. Beispiele truefalse | |||
Geforderter Betrag ClaimedAmount | Der vom Versicherungsnehmer ursprünglich geltend gemachte Gesamtbetrag. | ||
Beschreibung Dieses Attribut steht für die vom Anspruchsteller gemeldete Schadensumme. Sie ist oft eine erste Schätzung und kann sich im Zuge der Prüfung und der Bildung von Rückstellungen ändern. Die Analyse der gemeldeten Schadensumme ermöglicht eine Segmentierung nach finanzieller Wirkung. Fälle mit hohen Beträgen durchlaufen in der Regel einen strengeren, komplexeren Prozess als kleinere. Der Vergleich zwischen Betragsklassen zeigt, wo sich die Bearbeitung kleiner Schäden verschlanken lässt oder wo bei großen Fällen strengere Kontrollen sinnvoll sind. Warum es wichtig ist Ermöglicht die Segmentierung nach Schadenshöhe, da Fälle mit hoher Schadenssumme oft andere, komplexere Prozesse durchlaufen. Woher erhalten Diese Information ist oft kein einzelnes Feld, sondern kann aus den anfänglichen Schaden- bzw. Verlustschätzungen abgeleitet werden, die auf Exposures erfasst wurden. Beispiele 5000.00150000.00750.50 | |||
Ist automatisiert IsAutomated | Kennzeichen (Flag), ob eine Aktivität automatisch vom System oder manuell durch einen Benutzer ausgeführt wurde. | ||
Beschreibung Dieses boolesche Attribut unterscheidet Aktivitäten, die durch ein System ausgeführt werden (z. B. automatische Reservebildung, systemgenerierte Korrespondenz), von Aktivitäten, die ein Bearbeiter manuell erledigt. Die Analyse dieses Attributs ist entscheidend, um den Automatisierungsgrad im Schadenprozess zu verstehen. So lassen sich Hotspots manueller Eingriffe identifizieren, die Wirkung von Initiativen zur Dunkelverarbeitung (Straight-Through Processing, STP) messen und neue Automatisierungschancen finden – insbesondere bei repetitiven, regelbasierten Aufgaben, die heute noch Menschen ausführen. Warum es wichtig ist Unterscheidet zwischen systemgesteuerten und manuell ausgeführten Aktivitäten – entscheidend für Automatisierungsanalysen und das Auffinden manueller Engpässe. Woher erhalten Dies muss häufig abgeleitet werden. Beispielsweise können Events, die von einem generischen 'system'-User protokolliert wurden, als automatisiert gekennzeichnet werden. Beispiele truefalse | |||
Letzte Datenaktualisierung LastDataUpdate | Zeitstempel, der angibt, wann die Daten zuletzt aktualisiert bzw. aus dem Quellsystem extrahiert wurden. | ||
Beschreibung Dieses Attribut liefert den Timestamp des jüngsten Abrufs aus dem Quellsystem. Es handelt sich um ein Metadatenfeld, das für das Verständnis der Aktualität der Analyse entscheidend ist. Dashboards und Analysen sollten diese Information prominent anzeigen, damit Nutzerinnen und Nutzer die Aktualität der Daten kennen. So lässt sich einschätzen, ob die Erkenntnisse den aktuellen Stand der Vorgänge widerspiegeln oder auf älteren Daten beruhen. Warum es wichtig ist Gibt die Aktualität der Daten an und stellt sicher, dass Nutzende verstehen, wie aktuell die Prozessanalyse ist. Woher erhalten Dieser Wert wird während des ETL-Prozesses erzeugt und gespeichert und entspricht dem Zeitstempel des Datenimports. Beispiele 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Nacharbeit IsRework | Kennzeichen (Flag), ob eine Aktivität eine Nacharbeitsschleife darstellt – also eine Rückkehr in einen vorherigen Prozessschritt. | ||
Beschreibung Dieses berechnete Attribut markiert Aktivitäten, die Teil einer Nacharbeitsschleife sind. Wenn der Prozess z. B. von 'Investigation Completed' zurück zu 'Investigation Started' springt, wird die zweite Aktivität 'Investigation Started' als Rework gekennzeichnet. Das Erkennen von Rework ist grundlegend, um Ineffizienzen und Qualitätsprobleme aufzudecken. Das Dashboard 'Rework- und Ablehnungshäufigkeit' basiert auf dieser Kennzahl, um zu quantifizieren, wie oft Fälle vom idealen 'Happy Path' abweichen. Die Analyse der Ursachen von Rework kann die Prozessqualität und -geschwindigkeit deutlich verbessern. Warum es wichtig ist Markiert explizit Aktivitäten, die zu Nacharbeiten gehören, und macht so Ineffizienzen und Qualitätsprobleme im Prozess sichtbar. Woher erhalten Dies wird im Process-Mining-Tool berechnet, indem die Abfolge der Aktivitäten je Fall analysiert wird. Beispiele truefalse | |||
Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
Beschreibung Dieses Attribut kennzeichnet die Herkunft der Events. In modernen Systemlandschaften können schadenrelevante Events aus mehreren Systemen stammen, etwa aus einem Kernsystem wie Guidewire, einem Dokumentenmanagementsystem oder einem Kundenportal. Die Angabe des Quellsystems ist essenziell für Data Governance, zur Behebung von Inkonsistenzen und zum Verständnis der technologischen Prozesslandschaft. So lassen sich Kernprozessschritte von unterstützenden Aktivitäten aus peripheren Systemen unterscheiden. Warum es wichtig ist Ermittelt die Herkunft der Daten – entscheidend für Data Governance und Analysen über mehrere integrierte Systeme hinweg. Woher erhalten Dies ist typischerweise ein statischer Wert, der im ETL-Prozess hinzugefügt wird. Beispiele Guidewire ClaimCenter v10Customer Portal APIDocumentum | |||
Schadendatum LossDate | Das Datum, an dem das Ereignis bzw. der Schaden eingetreten ist, der den Claim ausgelöst hat. | ||
Beschreibung Das Date of Loss (Schadendatum) ist das Datum des eigentlichen Ereignisses (z. B. Autounfall, Sachschaden), für das der Claim gemeldet wird. Es unterscheidet sich vom Meldedatum bzw. Erstellungsdatum des Claims. Die Zeitspanne zwischen dem Schadendatum und der Aktivität 'Claim Created' (Reporting Lag) ist eine wichtige KPI. Ihre Analyse liefert Einblicke in das Kundenverhalten und die Wirksamkeit der First-Notice-of-Loss-Kanäle. Warum es wichtig ist Bietet wichtigen Kontext zur Herkunft des Schadens und unterstützt die Analyse des Meldeverzugs (Zeit vom Ereignis bis zur Schadenmeldung). Woher erhalten Dies ist ein grundlegendes Datumsfeld der Entität 'Claim', häufig 'LossDate' genannt. Beispiele 2023-05-102023-04-202023-05-28 | |||
SLA-Status SLAState | Zeigt an, ob der Schaden innerhalb des Zieltermins abgeschlossen wurde. | ||
Beschreibung Dieses berechnete Attribut liefert für jeden abgeschlossenen Schadenfall einen kategorischen Status zur SLA-Einhaltung. Es entsteht durch den Vergleich des Zeitstempels der Aktivität 'Claim Closed' mit dem 'Resolution Target Date'. Das Attribut unterstützt das Dashboard 'Claim Resolution Target Adherence', indem es die Analyse in klare Kategorien wie 'On Time' oder 'Late' einteilt. So lassen sich Fälle einfach filtern und zusammenfassen, die Gesamtquote der SLA-Einhaltung berechnen und Verzögerungsursachen gezielt nachvollziehen. Warum es wichtig ist Liefert ein klares, kategoriales Ergebnis zur SLA-Einhaltung – ideal zum Filtern, Aggregieren und Analysieren der Termintreue. Woher erhalten Berechnetes Feld: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Beispiele PünktlichÜberfällig | |||
Vertragsart PolicyType | Die konkrete Art der Police, unter der der Claim gemeldet wurde. | ||
Beschreibung Die Vertragsart bietet eine feinere Klassifizierung als der Schadenstyp und beschreibt das konkrete Versicherungsprodukt, z. B. 'Wohngebäude', 'Gewerbe-Kfz' oder 'Cyber-Versicherung'. Diese Detailtiefe macht produktspezifische Prozessvarianten sichtbar. Die Analyse nach Vertragsart deckt produktspezifische Ineffizienzen auf. Bei neu eingeführten Produkten ist der Prozess oft weniger reif – das führt zu Verzögerungen. Die Erkenntnisse unterstützen Produktgestaltung und Standardisierung. Warum es wichtig ist Ermöglicht die Prozessanalyse für konkrete Versicherungsprodukte und zeigt Unterschiede in der Bearbeitung je nach Policenmerkmalen. Woher erhalten Diese Information befindet sich in der Entität 'Policy', die mit dem Claim verknüpft ist. Beispiele Wohngebäude (Mehrgefahren)Gewerbliche Kfz-HaftpflichtTransportversicherung (Binnenland) | |||
Zahlungsbetrag PaymentAmount | Der tatsächlich ausgezahlte Betrag für eine Zahlungsaktivität. | ||
Beschreibung Dieses Attribut erfasst den Betrag jeder einzelnen Zahlung zu einem Schadenfall. Ein Schadenfall kann über seinen Lebenszyklus mehrere Zahlungen enthalten. Das ist zentral für finanzielle Analysen im Kontext von Process Mining. So lässt sich die Gesamtauszahlung pro Schadenfall nachverfolgen, die Zahlungsfreigabezeiten in Abhängigkeit vom Betrag analysieren und der Zusammenhang zwischen Prozesseffizienz und finanziellen Ergebnissen herstellen. Beispiel: Schadenfälle mit langen Durchlaufzeiten korrelieren häufig mit höheren Gesamtzahlungen. Warum es wichtig ist Verfolgt die finanziellen Transaktionen innerhalb eines Claims und ermöglicht die Analyse von Zahlungsbeträgen und deren Zusammenhang mit Prozessaktivitäten. Woher erhalten Zu finden in zahlungsbezogenen Entitäten, die mit dem Schadenfall verknüpft sind – häufig in einer Transaction- oder Check-Tabelle. Beispiele 4500.00125000.00500.00 | |||
Zieldatum der Regulierung ResolutionTargetDate | Das Datum, bis zu dem der Schadenfall gemäß internen oder regulatorischen SLAs voraussichtlich abgeschlossen sein soll. | ||
Beschreibung Das Zieldatum für die Regulierung ist die Frist für den Abschluss eines Claims. Es ergibt sich häufig aus Faktoren wie Rechtsraum, Schadentyp und Vertragsbedingungen und dient als Maßstab für Performance und Compliance. Dieses Attribut ist zentral für SLA-Dashboards und KPIs. Der Abgleich des tatsächlichen 'Claim Closed'-Datums mit dem Zieldatum markiert verspätete Fälle automatisch, misst Pünktlichkeitsquoten und zeigt, welche Schadentypen oder Bereiche ihre Ziele verfehlen. Warum es wichtig ist Das ist der Referenzwert, um die Einhaltung von Service Level Agreements (SLA) zu messen und Schadenfälle zu erkennen, bei denen eine Überschreitung droht. Woher erhalten Dies kann ein benutzerdefiniertes Feld sein oder auf Basis von in ClaimCenter konfigurierten Business Rules abgeleitet werden, eventuell bezogen auf spezifische Claim-Kennzahlen. Beispiele 2023-06-142023-07-202023-08-28 | |||
Aktivitäten in der Schadenbearbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
Erstreserve festgelegt | Kennzeichnet die Anlage der ersten finanziellen Rückstellung für ein Exposure zur Schätzung der voraussichtlichen Schadenkosten. Dieses zentrale finanzielle Ereignis wird explizit erfasst. | ||
Warum es wichtig ist Dieser Meilenstein ist zentral für die Finanzanalyse und das Verständnis, wie schnell die potenzielle Haftung bewertet wird. Verzögerungen können die Finanzplanung und das Reporting beeinträchtigen. Woher erhalten Dieses Event wird erfasst, wenn der erste cc_reserveline-Datensatz erstellt wird, der einer Exposure im Claim zugeordnet ist. Der CreateTime der Transaktion dient als Event-Zeitstempel. Erfassen Ermitteln Sie den kleinsten Creation-Timestamp aller Reservezeilen für die Schadenpositionen eines Schadenfalls. Ereignistyp explicit | |||
Schadenfall abgelehnt | Kennzeichnet die endgültige Ablehnung eines Schadenfalls und stellt das Endereignis des Prozesses dar. Dieses Ereignis wird abgeleitet, wenn der Claim-Status auf 'Closed' mit dem Ablehnungsgrund 'Denied' gesetzt wird. | ||
Warum es wichtig ist Dies ist ein kritisches Ergebnis-Event. Die Analyse von Häufigkeit, Gründen und Prozesspfaden, die zu Ablehnungen führen, deckt Probleme bei Schadenanlage, Untersuchung oder Policeninterpretation auf. Woher erhalten Abgeleitet aus einer Änderung des Feldes State in der Tabelle cc_claim auf 'Closed', kombiniert mit dem Feld CloseReason = 'Denied' oder einem ähnlichen Wert. Der Zeitstempel des Ereignisses ist das CloseDate. Erfassen Filtern Sie nach Statusänderungen des Schadenfalls auf 'Closed', bei denen der Reason Code auf eine Ablehnung hinweist. Ereignistyp inferred | |||
Schadenfall angelegt | Diese Aktivität markiert die Erstschadenmeldung (First Notice of Loss, FNOL) und die offizielle Anlage eines neuen Schadenfalls in Guidewire ClaimCenter. Sie wird explizit erfasst, wenn eine neue Claim-Entität erstmals in der Datenbank gespeichert wird. | ||
Warum es wichtig ist Als zentrales Start‑Event ist diese Aktivität die Basis zur Messung der End‑to‑End‑Durchlaufzeit. Sie liefert den Referenzpunkt für alle nachgelagerten Performance‑ und Dauer‑KPIs. Woher erhalten Dies ist ein explizites Event, das aus dem CreateTime der Tabelle cc_claim stammt. Die Anlage eines neuen Datensatzes mit einer eindeutigen Claim ID dient als Auslöser. Erfassen Ermitteln Sie den Zeitstempel der Erstellung des neuen Eintrags in der Basistabelle der Entität Claim. Ereignistyp explicit | |||
Schadenfall geschlossen | Kennzeichnet den erfolgreichen Abschluss eines Schadens, nachdem alle Aktivitäten und Zahlungen erledigt sind. Dies ist das primäre erfolgreiche Endereignis und wird aus der Änderung des Hauptstatus des Schadens abgeleitet. | ||
Warum es wichtig ist Als zentrales End‑Event ist diese Aktivität unerlässlich, um die End‑to‑End‑Durchlaufzeit zu berechnen und SLA‑Einhaltung zu messen. Sie markiert den Abschluss des Schadenlebenszyklus. Woher erhalten Abgeleitet aus einer Änderung des Feldes State in der Tabelle cc_claim auf 'Closed'. Der Zeitstempel des Ereignisses ist das CloseDate im Schadendatensatz. Erfassen Ermitteln Sie, wann das Hauptstatusfeld des Schadens auf 'Closed' gesetzt wird. Ereignistyp inferred | |||
Schadenposition angelegt | Diese Aktivität kennzeichnet die Anlage einer Schadenposition (Exposure), die eine spezifische potenzielle Haftung bzw. Schadenart innerhalb des Schadenfalls repräsentiert (z. B. Fahrzeugschaden, Personenschaden). Dies ist ein explizites Event in Guidewire. | ||
Warum es wichtig ist Schadenpositionen sind zentral für Segmentierung und Analyse. Das Tracking ihrer Anlage zeigt Prozessvarianten in Abhängigkeit von Komplexität und Schadensart. Woher erhalten Erfasst anhand des CreateTime eines neuen Eintrags in der Tabelle cc_exposure. Jeder Eintrag ist einer einzelnen Claim-ID zugeordnet. Erfassen Ermitteln Sie den Zeitstempel der Erstellung eines neuen Eintrags in der Tabelle der Entität Exposure. Ereignistyp explicit | |||
Zahlung angewiesen | Diese Aktivität kennzeichnet den letzten Schritt im Zahlungsprozess: Die Zahlung wird offiziell angewiesen und an das Finanzsystem übergeben. Es handelt sich um eine explizit protokollierte Finanztransaktion. | ||
Warum es wichtig ist Diese Aktivität ist zentral, um die Effizienz des Zahlungsprozesses zu messen. Sie hilft, Freigabeverzögerungen von Verzögerungen bei der eigentlichen Auszahlung zu unterscheiden. Woher erhalten Erfasst aus dem IssueDate oder bei einer Statusänderung auf 'Issued' bzw. 'Submitted' an der Entität cc_check oder cc_transaction. Dies ist häufig ein explizites, protokolliertes Ereignis mit Zeitstempel. Erfassen Ermitteln Sie das IssueDate oder den Zeitstempel der Statusänderung auf 'Issued' im Zahlungsdatensatz. Ereignistyp explicit | |||
Zahlung genehmigt | Kennzeichnet die formale Freigabe einer Entschädigungszahlung. Dieses wichtige Audit-Ereignis wird explizit erfasst, wenn ein berechtigter Benutzer die Transaktion genehmigt. | ||
Warum es wichtig ist Dieser Schlüsselmeilenstein schaltet den letzten Zahlungsschritt frei. Die Analyse der Zeiten vor und nach dieser Aktivität hilft, Verzögerungen durch Freigabe-Workflows oder die Verfügbarkeit der Genehmiger einzugrenzen. Woher erhalten Dies ist häufig ein explizites Event, das in der Tabelle cc_history im Zusammenhang mit einer Entität cc_check oder cc_transaction protokolliert wird und den Statuswechsel von 'Pending Approval' auf 'Approved' festhält. Erfassen Den Statuswechsel auf 'Approved' für eine bestimmte Zahlungstransaktion nachverfolgen. Ereignistyp explicit | |||
Additional Info Received | Kennzeichnet den Abschluss einer Anforderung zusätzlicher Informationen. Dies wird erfasst, wenn die zugehörige 'Activity' (Task) für die Informationsanforderung als 'Completed' markiert wird. | ||
Warum es wichtig ist Dies ist der Endpunkt für den KPI 'Additional Info Gathering Cycle Time'. Lange Zeiten zwischen Anforderung und Eingang sind eine häufige Verzögerungsquelle im Schadenprozess. Woher erhalten Erfasst anhand des CloseTime eines cc_activity-Datensatzes, dessen ActivityPattern sich auf eine Informationsanfrage bezieht. Der Aktivitätsstatus muss 'Completed' sein. Erfassen Ermitteln Sie den Zeitstempel für den Abschluss einer Aufgabe zur Anforderung externer Informationen. Ereignistyp explicit | |||
Additional Info Requested | Kennzeichnet eine Anfrage an den Anspruchsteller oder an Dritte, um zusätzliche Informationen oder Unterlagen einzuholen. In der Regel wird dafür eine eigene 'Activity' (Task) im ClaimCenter erstellt. | ||
Warum es wichtig ist Diese Aktivität ist der Startpunkt für die Messung des KPIs 'Durchlaufzeit für zusätzliche Informationen'. Häufiges Auftreten kann auf unvollständige Erstschadenmeldungen (First Notice of Loss, FNOL) oder eine ineffiziente Informationsbeschaffung hindeuten. Woher erhalten Erfasst anhand des CreateTime eines cc_activity-Datensatzes, dessen ActivityPattern die Anforderung von Unterlagen oder Informationen bei einer externen Stelle beschreibt. Erfassen Erkennen Sie die Anlage einer Aufgabe zur Anforderung externer Informationen. Ereignistyp explicit | |||
Entschädigung berechnet | Diese Aktivität steht dafür, dass ein Entschädigungsbetrag festgelegt wurde, aber noch keine Zahlungsfreigabe vorliegt. Das lässt sich aus der Anlage einer Zahlung im Status 'Pending Approval' ableiten. | ||
Warum es wichtig ist Kennzeichnet den Übergang von der Bewertung zur Zahlung. Er ist der Startpunkt zur Messung des KPIs 'Payment Authorization Lead Time' und macht Verzögerungen in der Genehmigungskette sichtbar. Woher erhalten Abgeleitet aus dem CreateTime eines cc_check- oder cc_transaction-Eintrags, dessen initialer Status 'Pending Approval' oder ein ähnlicher Zustand vor 'Approved' ist. Erfassen Erkennen Sie die Anlage eines Zahlungs- oder Transaktionsdatensatzes in einem vorab genehmigten Status. Ereignistyp inferred | |||
Haftungsentscheidung getroffen | Markiert den Zeitpunkt, an dem für eine Schadenposition eine Haftungsentscheidung getroffen wird. Dieses Ereignis wird typischerweise aus einer Statusänderung der Exposure-Entität abgeleitet. | ||
Warum es wichtig ist Dies ist ein kritischer Entscheidungsmeilenstein, der die Phasen Regulierung und Zahlung freischaltet. Die Analyse der Zeit bis zu dieser Entscheidung hilft, Engpässe in der Ermittlungs- und Bewertungsphase zu identifizieren. Woher erhalten Abgeleitet aus der Tabelle cc_history, indem eine Änderung des Feldes State oder eines benutzerdefinierten Haftungsstatusfeldes der Entity cc_exposure nachverfolgt wird. Der Zeitstempel des History-Eintrags gibt die Ereigniszeit an. Erfassen Überwachen Sie Audit-Logs bzw. History-Tabellen auf Änderungen am Zustand oder Haftungsstatus des Exposures. Ereignistyp inferred | |||
Schadenfall wiedereröffnet | Kennzeichnet, dass ein Schadenfall vom Status 'Closed' auf 'Open' zurückgesetzt wird, um weitere Arbeiten zu erledigen. Dieses Ereignis wird aus einer bestimmten Abfolge von Statuswechseln abgeleitet. | ||
Warum es wichtig ist Diese Aktivität steht für Nacharbeit. Ein hohes Volumen wiedereröffneter Schadenfälle weist auf Probleme bei der Erstregulierung, übersehene Schäden oder andere Prozessfehler hin – mit höheren Kosten und geringerer Effizienz als Folge. Woher erhalten Abgeleitet aus der Tabelle cc_history, indem eine Änderung des Feldes State der Entity cc_claim von 'Closed' zurück auf 'Open' oder einen anderen aktiven Status erkannt wird. Erfassen Überwachen Sie das Hauptstatusfeld des Schadens auf einen Übergang von einem geschlossenen in einen offenen Zustand. Ereignistyp inferred | |||
Schadenfall zugewiesen | Kennzeichnet die Zuweisung eines Schadenfalls an einen bestimmten Benutzer (Schadenbearbeiter) oder eine Gruppe. Dies wird typischerweise über Änderungen in den Zuweisungsfeldern der Claim-Entität erkannt. | ||
Warum es wichtig ist Das Nachverfolgen von Zuweisungen ist entscheidend, um die Auslastung der Sachbearbeiter zu analysieren, Routing-Engpässe zu erkennen und die Zeit bis zum ersten Bearbeitungsschritt des zugewiesenen Bearbeiters zu messen. Woher erhalten Abgeleitet aus der Tabelle cc_history, indem Änderungen an den Feldern AssignedUser oder AssignedGroup zu einer bestimmten Claim-ID nachverfolgt werden. Der Zeitstempel der Änderung zeigt an, wann das Ereignis stattgefunden hat. Erfassen Überwachen Sie Audit-Logs bzw. History-Tabellen auf Änderungen der Zuweisungsfelder des Schadens. Ereignistyp inferred | |||
Untersuchung gestartet | Kennzeichnet den formalen Beginn der Ermittlungsphase für einen Schaden oder eine Schadenposition. Oft wird dies aus der Anlage der ersten ermittlungsbezogenen 'Activity' (Aufgabe) in Guidewire abgeleitet. | ||
Warum es wichtig ist Diese Aktivität markiert den Beginn einer zentralen, oft langwierigen Phase. Die Analyse der Zeit bis zum Beginn der Schadenprüfung sowie der Dauer der Prüfung selbst offenbart wesentliche Engpässe. Woher erhalten Abgeleitet aus dem CreateTime eines cc_activity-Eintrags, bei dem das ActivityPattern der Untersuchung zugeordnet ist (z. B. 'Initial Investigation', 'Contact Witness'). Erfassen Erkennen Sie die erstmalige Anlage einer Aufgabe mit einem ermittlungsbezogenen Muster oder Betreff. Ereignistyp inferred | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen prüfen: Stellen Sie sicher, dass Sie die nötigen Berechtigungen und Zugangsdaten besitzen, um mit Leserechten auf die Data‑Mart‑Datenbank von Guidewire DataHub / InfoCenter zuzugreifen. Prüfen Sie außerdem, dass die ETL‑Jobs zur Befüllung des Claims‑Data‑Marts erfolgreich laufen und die Daten aktuell sind.
- Datenbankverbindung: Verwenden Sie einen gängigen SQL‑Client (z. B. DBeaver, SQL Server Management Studio oder ähnlich), um eine Verbindung zum Data‑Mart‑Datenbankserver herzustellen.
- Schema erkunden: Bevor Sie die vollständige Abfrage ausführen, machen Sie sich mit dem Schema des Data Marts vertraut. Identifizieren Sie die zentralen Tabellen für Schäden, Exposures/Schadenpositionen, Aktivitäten und Finanztransaktionen. Wichtige Tabellen enden typischerweise auf _dim (Dimension) und _fact (Fakt). So können Sie die Platzhalter für Tabellen‑ und Spaltennamen im Skript prüfen.
- SQL‑Abfrage vorbereiten: Kopieren Sie das komplette SQL‑Skript aus dem Abschnitt query in den Abfrage‑Editor Ihres SQL‑Clients.
- Platzhalter anpassen: Prüfen Sie das Skript sorgfältig und ersetzen Sie alle Platzhalterwerte. Dazu gehören Datenbank‑/Schema‑Name (z. B. [YourDataMart]), Datumsparameter ('[StartDate]', '[EndDate]') sowie systemspezifische Einstellungen (z. B. Aktivitätsmuster, Statuscodes).
- Abfrage ausführen: Führen Sie die angepasste SQL‑Abfrage gegen den Data Mart aus. Die Laufzeit hängt vom gewählten Zeitraum und dem Datenvolumen in Ihrem System ab.
- Erste Datenprüfung: Nach Abschluss der Abfrage sichten Sie die ersten paar Hundert Zeilen der Ergebnismenge. Prüfen Sie, ob die Spalten ClaimID, ActivityName und EventTime wie erwartet gefüllt sind und unterschiedliche Aktivitätstypen enthalten.
- Export als CSV: Exportieren Sie die gesamte Ergebnismenge aus Ihrem SQL‑Client in eine CSV‑Datei. Verwenden Sie einen aussagekräftigen Namen, z. B. guidewire_claimcenter_event_log.csv.
- Für ProcessMind formatieren: Speichern Sie die CSV‑Datei mit UTF‑8‑Kodierung. Stellen Sie sicher, dass eine Header‑Zeile vorhanden ist, die den Spaltenaliassen der SQL‑Abfrage entspricht. Die Datei kann nun in ProcessMind hochgeladen werden.
Konfiguration
- Datenquelle: Guidewire DataHub/InfoCenter Claims Data Mart. Eine voraggregierte, dimensional aufgebaute Datenbank für Reporting und Analytics – getrennt von der produktiven ClaimCenter-Datenbank.
- Erforderliche Berechtigungen: Lesezugriff auf die SQL-Datenbank, auf der der Data Mart gehostet wird. Sie benötigen Benutzername, Passwort sowie Verbindungsdaten (Serveradresse, Datenbankname).
- Status der ETL-Jobs: Die Datenqualität hängt von der erfolgreichen und rechtzeitigen Ausführung der Guidewire-ETL-Jobs ab, die den Data Mart befüllen. Prüfen Sie den Zeitpunkt des letzten erfolgreichen Laufs, um die Datenaktualität einzuschätzen.
- Filterung nach Zeitraum: Die bereitgestellte Abfrage enthält WHERE-Klauseln mit den Platzhaltern '[StartDate]' und '[EndDate]'. Starten Sie aus Performance-Gründen mit einem begrenzten Zeitraum (z. B. 3–6 Monate). Der Datumsfilter bezieht sich auf das CreateTime der Schadenmeldung.
- Konfigurationsabhängige Werte: Guidewire ist hochgradig konfigurierbar. Passen Sie die Werte in den WHERE-Klauseln an Ihre Systemkonfiguration an. Dazu gehören u. a.:
- ActivityPattern-Namen (z. B. 'fnol', 'investigation', 'Request additional information')
- Codes für ClaimStatus, ExposureStatus und CloseReason (z. B. 'denied', 'closed')
- TransactionStatus-Codes (z. B. 'pendingapproval', 'approved', 'issued')
- Performance: Abfragen großer History-/Audit-Tabellen sind ressourcenintensiv. Für sehr große Datenmengen empfiehlt sich die Ausführung außerhalb der Spitzenzeiten. Stellen Sie sicher, dass die Spalten ClaimID bzw. ClaimNumber in den relevanten Tabellen indiziert sind.
a Beispielabfrage sql
`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
- Voraussetzungen prüfen: Stellen Sie sicher, dass Sie die nötigen Berechtigungen und Zugangsdaten besitzen, um mit Leserechten auf die Data‑Mart‑Datenbank von Guidewire DataHub / InfoCenter zuzugreifen. Prüfen Sie außerdem, dass die ETL‑Jobs zur Befüllung des Claims‑Data‑Marts erfolgreich laufen und die Daten aktuell sind.
- Datenbankverbindung: Verwenden Sie einen gängigen SQL‑Client (z. B. DBeaver, SQL Server Management Studio oder ähnlich), um eine Verbindung zum Data‑Mart‑Datenbankserver herzustellen.
- Schema erkunden: Bevor Sie die vollständige Abfrage ausführen, machen Sie sich mit dem Schema des Data Marts vertraut. Identifizieren Sie die zentralen Tabellen für Schäden, Exposures/Schadenpositionen, Aktivitäten und Finanztransaktionen. Wichtige Tabellen enden typischerweise auf _dim (Dimension) und _fact (Fakt). So können Sie die Platzhalter für Tabellen‑ und Spaltennamen im Skript prüfen.
- SQL‑Abfrage vorbereiten: Kopieren Sie das komplette SQL‑Skript aus dem Abschnitt query in den Abfrage‑Editor Ihres SQL‑Clients.
- Platzhalter anpassen: Prüfen Sie das Skript sorgfältig und ersetzen Sie alle Platzhalterwerte. Dazu gehören Datenbank‑/Schema‑Name (z. B. [YourDataMart]), Datumsparameter ('[StartDate]', '[EndDate]') sowie systemspezifische Einstellungen (z. B. Aktivitätsmuster, Statuscodes).
- Abfrage ausführen: Führen Sie die angepasste SQL‑Abfrage gegen den Data Mart aus. Die Laufzeit hängt vom gewählten Zeitraum und dem Datenvolumen in Ihrem System ab.
- Erste Datenprüfung: Nach Abschluss der Abfrage sichten Sie die ersten paar Hundert Zeilen der Ergebnismenge. Prüfen Sie, ob die Spalten ClaimID, ActivityName und EventTime wie erwartet gefüllt sind und unterschiedliche Aktivitätstypen enthalten.
- Export als CSV: Exportieren Sie die gesamte Ergebnismenge aus Ihrem SQL‑Client in eine CSV‑Datei. Verwenden Sie einen aussagekräftigen Namen, z. B. guidewire_claimcenter_event_log.csv.
- Für ProcessMind formatieren: Speichern Sie die CSV‑Datei mit UTF‑8‑Kodierung. Stellen Sie sicher, dass eine Header‑Zeile vorhanden ist, die den Spaltenaliassen der SQL‑Abfrage entspricht. Die Datei kann nun in ProcessMind hochgeladen werden.
Konfiguration
- Datenquelle: Guidewire DataHub/InfoCenter Claims Data Mart. Eine voraggregierte, dimensional aufgebaute Datenbank für Reporting und Analytics – getrennt von der produktiven ClaimCenter-Datenbank.
- Erforderliche Berechtigungen: Lesezugriff auf die SQL-Datenbank, auf der der Data Mart gehostet wird. Sie benötigen Benutzername, Passwort sowie Verbindungsdaten (Serveradresse, Datenbankname).
- Status der ETL-Jobs: Die Datenqualität hängt von der erfolgreichen und rechtzeitigen Ausführung der Guidewire-ETL-Jobs ab, die den Data Mart befüllen. Prüfen Sie den Zeitpunkt des letzten erfolgreichen Laufs, um die Datenaktualität einzuschätzen.
- Filterung nach Zeitraum: Die bereitgestellte Abfrage enthält WHERE-Klauseln mit den Platzhaltern '[StartDate]' und '[EndDate]'. Starten Sie aus Performance-Gründen mit einem begrenzten Zeitraum (z. B. 3–6 Monate). Der Datumsfilter bezieht sich auf das CreateTime der Schadenmeldung.
- Konfigurationsabhängige Werte: Guidewire ist hochgradig konfigurierbar. Passen Sie die Werte in den WHERE-Klauseln an Ihre Systemkonfiguration an. Dazu gehören u. a.:
- ActivityPattern-Namen (z. B. 'fnol', 'investigation', 'Request additional information')
- Codes für ClaimStatus, ExposureStatus und CloseReason (z. B. 'denied', 'closed')
- TransactionStatus-Codes (z. B. 'pendingapproval', 'approved', 'issued')
- Performance: Abfragen großer History-/Audit-Tabellen sind ressourcenintensiv. Für sehr große Datenmengen empfiehlt sich die Ausführung außerhalb der Spitzenzeiten. Stellen Sie sicher, dass die Spalten ClaimID bzw. ClaimNumber in den relevanten Tabellen indiziert sind.
a Beispielabfrage sql
`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
- Voraussetzungen prüfen: Stellen Sie sicher, dass Sie die nötigen Berechtigungen und Zugangsdaten besitzen, um mit Leserechten auf die Data‑Mart‑Datenbank von Guidewire DataHub / InfoCenter zuzugreifen. Prüfen Sie außerdem, dass die ETL‑Jobs zur Befüllung des Claims‑Data‑Marts erfolgreich laufen und die Daten aktuell sind.
- Datenbankverbindung: Verwenden Sie einen gängigen SQL‑Client (z. B. DBeaver, SQL Server Management Studio oder ähnlich), um eine Verbindung zum Data‑Mart‑Datenbankserver herzustellen.
- Schema erkunden: Bevor Sie die vollständige Abfrage ausführen, machen Sie sich mit dem Schema des Data Marts vertraut. Identifizieren Sie die zentralen Tabellen für Schäden, Exposures/Schadenpositionen, Aktivitäten und Finanztransaktionen. Wichtige Tabellen enden typischerweise auf _dim (Dimension) und _fact (Fakt). So können Sie die Platzhalter für Tabellen‑ und Spaltennamen im Skript prüfen.
- SQL‑Abfrage vorbereiten: Kopieren Sie das komplette SQL‑Skript aus dem Abschnitt query in den Abfrage‑Editor Ihres SQL‑Clients.
- Platzhalter anpassen: Prüfen Sie das Skript sorgfältig und ersetzen Sie alle Platzhalterwerte. Dazu gehören Datenbank‑/Schema‑Name (z. B. [YourDataMart]), Datumsparameter ('[StartDate]', '[EndDate]') sowie systemspezifische Einstellungen (z. B. Aktivitätsmuster, Statuscodes).
- Abfrage ausführen: Führen Sie die angepasste SQL‑Abfrage gegen den Data Mart aus. Die Laufzeit hängt vom gewählten Zeitraum und dem Datenvolumen in Ihrem System ab.
- Erste Datenprüfung: Nach Abschluss der Abfrage sichten Sie die ersten paar Hundert Zeilen der Ergebnismenge. Prüfen Sie, ob die Spalten ClaimID, ActivityName und EventTime wie erwartet gefüllt sind und unterschiedliche Aktivitätstypen enthalten.
- Export als CSV: Exportieren Sie die gesamte Ergebnismenge aus Ihrem SQL‑Client in eine CSV‑Datei. Verwenden Sie einen aussagekräftigen Namen, z. B. guidewire_claimcenter_event_log.csv.
- Für ProcessMind formatieren: Speichern Sie die CSV‑Datei mit UTF‑8‑Kodierung. Stellen Sie sicher, dass eine Header‑Zeile vorhanden ist, die den Spaltenaliassen der SQL‑Abfrage entspricht. Die Datei kann nun in ProcessMind hochgeladen werden.
Konfiguration
- Datenquelle: Guidewire DataHub/InfoCenter Claims Data Mart. Eine voraggregierte, dimensional aufgebaute Datenbank für Reporting und Analytics – getrennt von der produktiven ClaimCenter-Datenbank.
- Erforderliche Berechtigungen: Lesezugriff auf die SQL-Datenbank, auf der der Data Mart gehostet wird. Sie benötigen Benutzername, Passwort sowie Verbindungsdaten (Serveradresse, Datenbankname).
- Status der ETL-Jobs: Die Datenqualität hängt von der erfolgreichen und rechtzeitigen Ausführung der Guidewire-ETL-Jobs ab, die den Data Mart befüllen. Prüfen Sie den Zeitpunkt des letzten erfolgreichen Laufs, um die Datenaktualität einzuschätzen.
- Filterung nach Zeitraum: Die bereitgestellte Abfrage enthält WHERE-Klauseln mit den Platzhaltern '[StartDate]' und '[EndDate]'. Starten Sie aus Performance-Gründen mit einem begrenzten Zeitraum (z. B. 3–6 Monate). Der Datumsfilter bezieht sich auf das CreateTime der Schadenmeldung.
- Konfigurationsabhängige Werte: Guidewire ist hochgradig konfigurierbar. Passen Sie die Werte in den WHERE-Klauseln an Ihre Systemkonfiguration an. Dazu gehören u. a.:
- ActivityPattern-Namen (z. B. 'fnol', 'investigation', 'Request additional information')
- Codes für ClaimStatus, ExposureStatus und CloseReason (z. B. 'denied', 'closed')
- TransactionStatus-Codes (z. B. 'pendingapproval', 'approved', 'issued')
- Performance: Abfragen großer History-/Audit-Tabellen sind ressourcenintensiv. Für sehr große Datenmengen empfiehlt sich die Ausführung außerhalb der Spitzenzeiten. Stellen Sie sicher, dass die Spalten ClaimID bzw. ClaimNumber in den relevanten Tabellen indiziert sind.
a Beispielabfrage sql
`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';
`