Datenvorlage: Schadenbearbeitung

Der Aktivitätsname beschreibt einen spezifischen Schritt, eine Aufgabe oder ein Ereignis innerhalb des Lebenszyklus der Schadenbearbeitung. Diese Aktivitäten repräsentieren die ausgeführte Arbeit, wie zum Beispiel 'Anspruch registriert', 'Untersuchung gestartet' oder 'Zahlung ausgestellt'. Jede Aktivität ist ein eigenständiger Punkt im Prozess, der im Event Log erfasst wird.

Für die Process Mining Analyse sind Aktivitäten die Bausteine der Prozesskarte. Die Analyse der Reihenfolge, Häufigkeit und Dauer dieser Aktivitäten enthüllt den tatsächlichen Prozessfluss, gängige Pfade, Engpässe und Abweichungen vom Standardverfahren. Eine klare und konsistente Benennung der Aktivitäten ist entscheidend für die Erstellung eines verständlichen und umsetzbaren Prozessmodells.

Aktivitäten bilden den Kern der Prozesslandkarte und definieren die Schritte und Aufgaben, deren Abfolge und Dauer analysiert werden, um die Prozessleistung zu verstehen.

Findet sich typischerweise in Event Logs, Audit Trails oder Transaktionsdatensätzen innerhalb des Schadenmanagementsystems.

Die Claim ID ist ein eindeutiger Schlüssel, der jedem Versicherungsfall bei seiner Registrierung zugewiesen wird. Sie ist das zentrale Bindeglied, das alle zugehörigen Aktivitäten, Events und Datenpunkte über den gesamten Lebenszyklus des Schadenfalls verbindet, von der ersten Einreichung bis zum endgültigen Abschluss.

Im Process Mining ist die Claim ID fundamental für die Rekonstruktion des End-to-End-Prozesses jedes Schadenfalls. Indem alle Events mit derselben Claim ID gruppiert werden, kann die Software den Prozessablauf visualisieren, Variationen identifizieren und fallbezogene Kennzahlen berechnen. Sie stellt sicher, dass jede Aktion, von der Sachbearbeiterzuweisung bis zur Zahlungsauszahlung, dem spezifischen Schadenfall korrekt zugeordnet wird, was eine kohärente und präzise Prozessanalyse ermöglicht.

Dies ist der wesentliche Case-Identifikator, der alle zugehörigen Events miteinander verknüpft und es so ermöglicht, den End-to-End-Verlauf jedes Schadenfalls nachzuverfolgen.

Findet sich typischerweise im Header oder Primärdatensatz einer Schadenakte oder einer Transaktion des Schadenmanagementsystems.

Der Start Time ist ein präziser Datums- und Zeitstempel, der den Beginn einer Aktivität kennzeichnet. Er ist ein kritischer Datenpunkt für jedes Event im Prozesslog und liefert den zeitlichen Kontext, der für die Performance-Analyse benötigt wird.

Im Process Mining ist der Start Time unerlässlich, um Events chronologisch zu ordnen und den Case Journey präzise zu rekonstruieren. Er bildet die Grundlage für die Berechnung wichtiger Key Performance Indicators wie Durchlaufzeiten, Wartezeiten und Bearbeitungszeiten. Die Analyse von Timestamps hilft, Verzögerungen zwischen den Schritten zu identifizieren, die Einhaltung von Service Level Agreements (SLAs) zu messen und die zeitliche Dynamik des Schadenbearbeitungsprozesses zu verstehen.

Dieser Timestamp ist unerlässlich, um Events korrekt zu ordnen und alle zeitbezogenen Metriken wie Durchlaufzeiten und Engpässe zu berechnen.

Wird typischerweise in Event Logs, Audit Trails oder Transaktionsdaten aufgezeichnet, oft als 'Event-Zeit' oder 'Erstellungsdatum' bezeichnet.

Die Letzte Datenaktualisierung gibt an, wann die Event Log-Daten zuletzt aus den Quellsystemen aktualisiert wurden. Dieser Timestamp liefert Kontext zur Aktualität der analysierten Daten und stellt sicher, dass Stakeholder über die Gültigkeit der Daten informiert sind.

In jeder Prozessanalyse ist das Wissen um die Aktualität der Daten entscheidend für fundierte Entscheidungen. Dieses Attribut hilft Nutzern zu verstehen, ob sie einen nahezu Echtzeitprozess oder eine historische Momentaufnahme betrachten. Es ist besonders wichtig für Dashboards zur kontinuierlichen Überwachung und um sicherzustellen, dass alle gezogenen Schlussfolgerungen auf relevanten und aktuellen Informationen basieren.

Bietet entscheidenden Kontext zur Aktualität der Daten und stellt sicher, dass Analysen und Entscheidungen auf aktuellen Informationen basieren.

Dies sind typischerweise Metadaten, die während des Datenextraktions-, Transformations- und Ladeprozesses (ETL-Prozess) generiert werden.

Das Attribut Source System gibt die spezifische IT-Anwendung oder Plattform an, auf der die Aktivität ursprünglich erfasst wurde. In komplexen Umgebungen können Schadenbearbeitungsdaten aus mehreren Systemen stammen, wie einer Kern-Schadenplattform, einem Dokumentenmanagementsystem oder einem Customer Relationship Management (CRM)-Tool.

Das Verständnis des Source Systems ist wertvoll für die Datenvalidierung und die Analyse der Prozessfragmentierung. Es hilft, Datenqualitätsprobleme bis zu ihrem Ursprung zurückzuverfolgen und kann Ineffizienzen aufdecken, die durch manuelle Datenübertragungen oder Arbeitsübergaben zwischen verschiedenen Systemen verursacht werden. Diese Analyse kann Möglichkeiten für eine bessere Systemintegration und Automatisierung aufzeigen.

Identifiziert den Ursprung von Event-Daten, was entscheidend für die Datenvalidierung und die Analyse der Prozessausführung über mehrere IT-Systeme hinweg ist.

Diese Information kann Teil der Datenextraktionslogik sein oder als Feld in den Event Logs integrierter Systeme gespeichert werden.

Das Attribut Abteilung gibt die organisatorische Gruppe an, die in einer bestimmten Phase des Lebenszyklus eines Schadenfalls verantwortlich ist. Beispiele hierfür sind 'Erstschadenmeldung', 'Untersuchungseinheit' oder 'Zahlungsabteilung'.

Diese Information ist entscheidend für das Verständnis von Übergaben und der Zusammenarbeit zwischen verschiedenen Bereichen der Organisation. Eine Analyse des Prozesses aus Abteilungsperspektive kann Verzögerungen aufdecken, die auftreten, wenn ein Schadenfall von einem Team zum nächsten wechselt. Sie hilft, abteilungsübergreifende Engpässe zu identifizieren und ist essenziell für die Bewertung teamspezifischer Arbeitslasten und Leistungen, und unterstützt so KPIs wie den Arbeitslastausgleich der Sachbearbeiter und Dashboards zur Team-Performance.

Unterstützt die Analyse von Prozessübergaben zwischen Teams und die Identifizierung abteilungsübergreifender Bottlenecks, was die Organisationsleistungsanalyse fördert.

Wird typischerweise im Schadendatensatz gespeichert, oft verknüpft mit dem zugewiesenen Benutzer oder der aktuellen Prozessphase.

Die End Time ist ein präziser Datums- und Zeitstempel, der den Moment des Abschlusses einer Aktivität anzeigt. Wenn sie zusammen mit einer Start Time verfügbar ist, ermöglicht sie die exakte Messung der Dauer einer Aktivität.

Dieses Attribut ist äußerst wertvoll für eine detaillierte Performance-Analyse. Die Differenz zwischen Start Time und End Time liefert die 'Bearbeitungszeit' oder 'Aktivitätsdauer', eine Schlüsselmetrik zur Identifizierung ineffizienter Schritte. Die Analyse von Bearbeitungszeiten hilft, festzustellen, welche Aktivitäten die meisten Ressourcen verbrauchen und wo die Bemühungen zur Prozessoptimierung konzentriert werden sollten. Sie ist fundamental für die Erstellung von Dashboards zu Prozessengpässen und zur Team-Performance.

Ermöglicht die präzise Berechnung von Bearbeitungszeiten für Aktivitäten, entscheidend für Engpassanalyse und Ressourceneffizienz.

Findet sich typischerweise in Event Logs oder Audit Trails zusammen mit der Startzeit. Es muss möglicherweise abgeleitet werden, wenn nur Änderungs-Events protokolliert werden.

Der Settlement Amount stellt den gesamten Geldbetrag dar, der zur Regulierung eines Schadenfalls ausgezahlt wird. Dies ist eine entscheidende Ergebniskennzahl, die den finanziellen Einfluss des Schadenfalls widerspiegelt. Er wird in der Regel ermittelt, nachdem der Schaden bewertet und eine Entscheidung getroffen wurde.

Im Process Mining ist dieses Attribut essenziell für die kostenbasierte Analyse. Es ermöglicht die Berechnung von KPIs wie den 'Durchschnittlichen Kosten pro Schadenfall' und die Untersuchung, wie Prozessvariationen finanzielle Ergebnisse beeinflussen. So könnte die Analyse beispielsweise zeigen, dass Schadenfälle mit bestimmten Nacharbeitschleifen oder längeren Zykluszeiten tendenziell zu höheren Abwicklungsbeträgen führen. Dies stellt eine direkte Verbindung zwischen Prozesseffizienz und finanzieller Leistung her und bildet die Grundlage für das Dashboard 'Schadenkostenanalyse'.

Dies ist eine wichtige Ergebnismetrik, die das Prozessverhalten direkt mit dem finanziellen Einfluss verknüpft und eine Kosten-Nutzen-Analyse von Prozessverbesserungen ermöglicht.

In den mit dem Schadensfall verbundenen Finanz- oder Zahlungsunterlagen zu finden, abgeschlossen bei Schadensfallschließung oder Zahlung.

Die Schadenschwere (Claim Severity) bewertet die Komplexität, Dringlichkeit oder die potenziellen finanziellen Kosten eines Anspruchs. Diese Klassifizierung hilft, Ansprüche zu priorisieren und sie den Schadensregulierern mit dem passenden Fachwissen zuzuweisen. Die Schwere kann durch Faktoren wie den geschätzten Schadensbetrag, die Art des Vorfalls oder das Vorhandensein von Rechtsstreitigkeiten bestimmt werden.

Die Analyse des Prozesses anhand der Schadenschwere ist entscheidend, um zu verstehen, ob die Bearbeitungsverfahren angemessen sind. Bei Ansprüchen mit hoher Schwere sind beispielsweise längere Durchlaufzeiten zu erwarten; sie sollten jedoch einem strengeren Untersuchungspfad folgen. Dieses Attribut hilft zu überprüfen, ob komplexe Ansprüche die nötige Aufmerksamkeit erhalten, während einfache Ansprüche schnell bearbeitet werden, wodurch die Ressourcenzuweisung und Kundenzufriedenheit optimiert werden.

Hilft, einfache und komplexe Schadensfälle zu unterscheiden und zu analysieren, ob die Prozessausführung der Komplexität des Falls angemessen angepasst ist.

Wird oft durch Geschäftsregeln bei der Schadenaufnahme festgelegt und als Feld im zentralen Anspruchsdatensatz gespeichert.

Die Schadensart (Claim Type) ist eine Klassifizierung, die Ansprüche nach Geschäftsbereich oder Art des Verlusts kategorisiert, wie zum Beispiel 'KFZ', 'Sach', 'Haftpflicht' oder 'Invalidität'. Verschiedene Schadensarten folgen oft unterschiedlichen Prozesspfaden und haben unterschiedliche Komplexitätsstufen sowie SLAs.

Die Segmentierung der Prozessanalyse nach Schadensart ist eine grundlegende Technik, um aussagekräftige Einblicke zu gewinnen. Sie ermöglicht den Vergleich von Durchlaufzeiten, Kosten und Prozesskonformität über verschiedene Kategorien hinweg. Diese Analyse kann aufdecken, dass ein für KFZ-Ansprüche effizienter Prozess für Sachschäden ineffizient sein kann und so gezielte Verbesserungsmaßnahmen ermöglicht. Dieses Attribut ist essenziell für das Dashboard 'Leistung nach Anspruchskategorie'.

Ermöglicht die Segmentierung von Schadenfällen, um Prozesse und Leistungen über verschiedene Geschäftsbereiche hinweg zu vergleichen und kategoriespezifische Probleme aufzudecken.

Ein Standardfeld im Hauptschadensdatensatz, das typischerweise bei der erstmaligen Erstellung des Schadenfalls gesetzt wird.

Das Zieldatum der Regulierung, oder Fälligkeitsdatum, ist die Frist, die für den Abschluss des Schadenbearbeitungsprozesses festgelegt wird. Dieses Datum wird oft durch regulatorische Vorgaben oder interne Service-Level-Agreements (SLAs) bestimmt, die einen zeitnahen Kundenservice gewährleisten sollen.

Dieses Attribut ist fundamental für die Compliance- und Performance-Überwachung. Durch den Vergleich des tatsächlichen Abschlussdatums des Schadenfalls mit dem Zieldatum können Organisationen ihre SLA-Einhalterate messen. Process Mining kann aufzeigen, welche Prozessschritte oder -varianten am ehesten zu SLA-Verstößen führen. Dies ermöglicht ein proaktives Fristenmanagement und hilft, Verbesserungen zu priorisieren, die den größten Einfluss auf eine zeitnahe Regulierung haben, was direkt das Dashboard 'SLA- und Fristeneinhaltung' unterstützt.

Ermöglicht die Messung der termingerechten Leistung im Vergleich zu SLAs oder gesetzlichen Fristen – eine entscheidende Messgröße für die Prozesseffektivität.

Wird typischerweise basierend auf Geschäftsregeln berechnet, wenn ein Schadenfall erstellt und im Hauptschadendatensatz gespeichert wird.

Der zugewiesene Sachbearbeiter identifiziert den einzelnen Mitarbeiter oder Benutzer, der eine bestimmte Aktivität ausgeführt hat oder zu einem bestimmten Zeitpunkt für den Schadenfall verantwortlich ist. Dieses Attribut verknüpft Prozessschritte mit den ausführenden Ressourcen.

Die Analyse von Daten nach Sachbearbeiter ist entscheidend für das Arbeitslastmanagement, die Leistungsbewertung und die Identifizierung von Schulungsbedarfen. Sie ermöglicht es Managern, die Performance der Teammitglieder zu vergleichen, eine gerechte Arbeitsverteilung sicherzustellen und Leistungsträger oder diejenigen zu erkennen, die zusätzliche Unterstützung benötigen könnten. Diese ressourcenbezogene Sichtweise ist essenziell für Dashboards zur Team-Performance und zum Arbeitslastausgleich.

Verknüpft Prozessaktivitäten mit den Personen, die sie ausführen, was die Analyse von Arbeitslast, Teamleistung und Ressourcenzuweisung ermöglicht.

Gefunden in Transaktionsdatensätzen, Audit-Logs oder Benutzerzuweisungsfeldern innerhalb des Schadensmanagementsystems.

Der Ablehnungsgrund ist ein Code oder eine Textbeschreibung, die erklärt, warum ein Schadenfall nicht bezahlt wurde. Gründe können von Problemen mit der Deckung gemäß Police über betrügerische Aktivitäten bis hin zur Nichtvorlage erforderlicher Unterlagen reichen.

Die Analyse von Ablehnungsgründen ist entscheidend, um Möglichkeiten zur Verbesserung sowohl interner Prozesse als auch der Kundenkommunikation zu identifizieren. Wenn beispielsweise eine große Anzahl von Schadenfällen aufgrund fehlender Informationen abgelehnt wird, kann dies auf die Notwendigkeit hinweisen, den Erfassungsprozess zu verbessern. Eine Ursachenanalyse der Ablehnungsgründe kann zu einer klareren Policensprache, einer besseren Kundenaufklärung und einem reduzierten administrativen Aufwand für letztendlich abgelehnte Schadenfälle führen.

Bietet Einblicke, warum Ansprüche nicht bezahlt werden, und ermöglicht eine Ursachenanalyse zur Verbesserung der Kundenkommunikation und der Front-End-Prozesse.

Aus einer vordefinierten Liste ausgewählt oder als Text von einem Sachbearbeiter eingegeben, wenn eine Aktivität 'Anspruch abgelehnt' auftritt.

Der Submission Channel identifiziert, wie ein Schadenfall erstmals an das Unternehmen gemeldet wurde. Gängige Kanäle sind ein Online-Kundenportal, eine mobile App, ein Agent, ein Makler oder traditionelle Post.

Die Analyse des Prozesses nach Einreichungskanal kann wichtige Unterschiede in Datenqualität, Effizienz und Kundenerfahrung aufzeigen. Zum Beispiel können über ein digitales Portal eingereichte Schadenfälle weniger Dateneingabefehler und schnellere anfängliche Bearbeitungszeiten aufweisen als solche, die per Post eingereicht werden. Diese Erkenntnisse können strategische Entscheidungen darüber beeinflussen, welche Kanäle gefördert werden sollen und wo in Automatisierung und Prozessverbesserung investiert werden sollte.

Hilft bei der Analyse, wie der Erfassungskanal die Prozesseffizienz, Datenqualität und die gesamte Durchlaufzeit beeinflusst.

Wird typischerweise während des 'First Notice of Loss' (FNOL) Prozesses erfasst und im Hauptschadendatensatz gespeichert.

Der Forderungsbetrag ist die ursprüngliche Schätzung des Schadens oder der vom Antragsteller zu Beginn des Prozesses geforderte Betrag. Dieser Wert kann später während der Untersuchungs- und Bewertungsphase angepasst werden.

Dieses Attribut ist für verschiedene Arten von Analysen nützlich. Es kann verwendet werden, um einen anfänglichen Schweregrad für den Schadenfall festzulegen und die Abweichung zwischen dem ursprünglichen Forderungsbetrag und dem endgültigen Abwicklungsbetrag zu verfolgen. Die Analyse dieser Abweichung kann Einblicke in die Genauigkeit der ursprünglichen Schätzungen und die Wirksamkeit der Kostenkontrollmaßnahmen innerhalb des Schadenbearbeitungsprozesses liefern. Es ist eine wichtige Grundlage für Finanzprognosen und Rückstellungen.

Stellt den anfänglichen finanziellen Umfang des Anspruchs dar, nützlich für die Schweregradbewertung und die Analyse der Abweichung vom endgültigen Vergleichsbetrag.

Erfasst während des anfänglichen Schadenanmeldungsprozesses und gespeichert im Finanzbereich des Schadensdatensatzes.

Die Policy Number ist die eindeutige Referenznummer für den Versicherungsvertrag, der den gemeldeten Schaden abdeckt. Sie verknüpft den Schadenfall mit einem bestimmten Kunden, Policenbedingungen, Deckungslimits und anderen vertraglichen Details.

Obwohl nicht immer direkt in der Prozessflussanalyse selbst verwendet, ist die Policy Number eine entscheidende Kontextinformation. Sie ermöglicht die Aggregierung von Schadenfalldaten auf Policen- oder Kundenebene, wodurch Muster wie häufige Schadenfälle eines einzelnen Versicherungsnehmers aufgedeckt werden können. Zudem ermöglicht sie die Anreicherung der Schadenfalldaten mit policenbezogenen Details (z. B. Policenart, Deckungssumme) für eine fortgeschrittene Segmentierung und Analyse.

Verknüpft den Schadensfall mit dem spezifischen Versicherungsvertrag, was eine Anreicherung mit Policendaten für eine tiefere, kontextbezogenere Analyse ermöglicht.

Ein fundamentales Datenelement, das bei der Schadenaufnahme erfasst und im Header des Schadensdatensatzes gespeichert wird.

Das Schadensdatum markiert das tatsächliche Datum des Ereignisses (z. B. Autounfall, Sachschaden), das zum Schadenfall führte. Dies unterscheidet sich von dem Datum, an dem der Schadenfall im System gemeldet oder registriert wurde.

Die Differenz zwischen dem Schadensdatum und dem Registrierungsdatum des Schadenfalls wird als 'Meldeverzug' bezeichnet. Die Analyse dieses Verzugs ist wichtig für das Verständnis des Kundenverhaltens und die Identifizierung potenzieller Betrugsrisiken (z. B. ungewöhnlich lange Meldeverzögerungen). Sie bietet eine vollständigere Zeitachse der gesamten Schadenabwicklung, vom Vorfall bis zur Lösung, und somit eine breitere Sicht als nur die interne Bearbeitungszeit.

Legt das Datum des tatsächlichen Vorfalls fest und ermöglicht so die Analyse von Meldeverzögerungen und der gesamten Zeitachse vom Event bis zum Abschluss.

Wird vom Antragsteller bei der 'Erstmeldung des Schadens' bereitgestellt und im zentralen Anspruchsdatensatz gespeichert.

Der Anspruchsstatus (Claim Status) gibt den Zustand eines Anspruchs innerhalb seines Lebenszyklus zum Zeitpunkt eines Events an. Dieser Status bietet einen Überblick darüber, wo sich der Anspruch im Prozess befindet, zum Beispiel 'In Untersuchung', 'Informationen ausstehend' oder 'Beglichen'.

Während Process Mining den detaillierten Ablauf der Aktivitäten rekonstruiert, bietet das Attribut 'Anspruchsstatus' eine wertvolle kontextuelle Ebene. Es kann verwendet werden, um den Prozessfluss zu validieren (z.B. führt eine Aktivität 'Zahlung geleistet' korrekt zum Status 'Abgeschlossen'?) und die Verweildauer von Ansprüchen in bestimmten Zuständen zu analysieren. Dies hilft zu verstehen, wie lange Fälle anhängig bleiben, und kann systemische Verzögerungen oder Ineffizienzen aufzeigen.

Bietet Kontext zum Zustand eines Anspruchs zu jedem Zeitpunkt, hilft bei der Analyse der in verschiedenen Phasen verbrachten Zeit und validiert den Prozessfluss.

Ein Kernfeld im Hauptschadensdatensatz, das aktualisiert wird, während der Schadenfall seinen Lebenszyklus durchläuft.