Ihr Daten-Template für die Schadenbearbeitung

Guidewire ClaimCenter
Ihr Daten-Template für die Schadenbearbeitung

Ihr Daten-Template für die Schadenbearbeitung

Hier finden Sie die wichtigsten Informationen zur Optimierung Ihrer Schadenbearbeitung. Dieses Template beschreibt, welche Datenattribute Sie erfassen und welche Aktivitäten Sie nachverfolgen sollten. Außerdem enthält es konkrete Hinweise zur Datenextraktion. So stellen Sie sicher, dass alle erforderlichen Informationen für eine umfassende Prozessanalyse vorliegen.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Hinweise zur Datenextraktion aus Guidewire ClaimCenter
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute der Schadenbearbeitung

Diese empfohlenen Datenfelder sind wichtig, um ein vollständiges Event Log zu erstellen und Ihre Workflows in der Schadenbearbeitung wirksam zu analysieren.
3 Erforderlich 4 Empfohlen 14 Optional
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
Erforderlich Empfohlen Optional

Aktivitäten der Schadenbearbeitung

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um den Schadenprozess präzise zu entdecken und zu analysieren.
7 Empfohlen 7 Optional
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
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Guidewire ClaimCenter

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.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.