Datenvorlage: Schadenbearbeitung

Guidewire ClaimCenter
Datenvorlage: Schadenbearbeitung

Ihr Data Template für die Schadenbearbeitung

Willkommen bei Ihrer zentralen Ressource zur Optimierung der Schadenbearbeitung. Diese Vorlage zeigt, welche Datenattribute Sie erfassen sollten, welche kritischen Aktivitäten nachzuverfolgen sind, und gibt klare Hinweise zur Datenextraktion. So stellen Sie sicher, dass alle nötigen Informationen für eine umfassende Prozessanalyse vorliegen.
  • Empfohlene Attribute zur Erfassung
  • Wichtige zu verfolgende Aktivitäten
  • Extraktionsleitfaden für Guidewire ClaimCenter
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Attribute der Schadenbearbeitung

Diese empfohlenen Datenfelder sind entscheidend, um ein vollständiges Event Log aufzubauen und Ihre Workflows in der Schadenbearbeitung effektiv zu analysieren.
3 Erforderlich 4 Empfohlen 15 Optional
NameBeschreibung
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
Erforderlich Empfohlen Optional

Aktivitäten in der Schadenbearbeitung

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie in Ihrem Event-Log erfassen sollten, um den Schadenprozess präzise zu entdecken und zu analysieren.
7 Empfohlen 7 Optional
AktivitätBeschreibung
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
Empfohlen Optional

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus dem Guidewire ClaimCenter