Ihr Daten-Template für die Schadenbearbeitung

Der Aktivitätsname bezeichnet einen bestimmten Schritt, eine Aufgabe oder ein Ereignis im Verlauf der Schadenbearbeitung. Dazu gehören beispielsweise „Schaden registriert“, „Untersuchung begonnen“ oder „Zahlung angewiesen“. Jede Aktivität ist ein eigener Prozessschritt, der im Event Log erfasst wird.

Bei der Process-Mining-Analyse bilden Aktivitäten die Bausteine der Prozesslandkarte. Die Analyse ihrer Reihenfolge, Häufigkeit und Dauer zeigt den tatsächlichen Prozessablauf, typische Pfade, Engpässe und Abweichungen von der Standardvorgehensweise. Klare und einheitliche Aktivitätsnamen sind entscheidend für ein verständliches und umsetzbares Prozessmodell.

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

Üblicherweise in Event Logs, Prüfprotokollen oder Transaktionsdatensätzen des Schadenmanagementsystems zu finden.

Die Claim-ID ist ein eindeutiger Schlüssel, der jedem Versicherungsschaden bei seiner Registrierung zugewiesen wird. Sie bildet den zentralen Bezugspunkt für alle zugehörigen Aktivitäten, Ereignisse und Datenpunkte während des gesamten Schadenverlaufs, von der ersten Meldung bis zum endgültigen Abschluss.

Im Process Mining ist die Claim-ID entscheidend, um den durchgängigen Verlauf jedes Schadens zu rekonstruieren. Gruppiert die Software alle Ereignisse mit derselben Claim-ID, kann sie den Prozessablauf visualisieren, Abweichungen erkennen und Kennzahlen auf Case-Ebene berechnen. So wird jede Aktion, von der Zuweisung an einen Schadenregulierer bis zur Zahlungsanweisung, dem richtigen Schaden zugeordnet. Das ermöglicht eine schlüssige und präzise Prozessanalyse.

Diese zentrale Case-Kennung verknüpft alle zugehörigen Ereignisse und ermöglicht es, den gesamten Verlauf jedes Schadens nachzuverfolgen.

Üblicherweise im Kopfbereich oder im Hauptdatensatz einer Schadenakte beziehungsweise einer Transaktion im Schadenmanagementsystem zu finden.

Die Startzeit ist ein genauer Zeitstempel, der den Beginn einer Aktivität festhält. Sie ist ein wichtiger Datenpunkt für jedes Ereignis im Prozessprotokoll und liefert den zeitlichen Kontext für die Leistungsanalyse.

Im Process Mining ist die Startzeit erforderlich, um Ereignisse chronologisch zu ordnen und den Verlauf eines Cases präzise zu rekonstruieren. Sie bildet die Grundlage für die Berechnung wichtiger Leistungskennzahlen wie Zykluszeiten, Wartezeiten und Verarbeitungszeiten. Die Analyse von Timestamps hilft, Verzögerungen zwischen Prozessschritten zu erkennen, die Einhaltung von Service Level Agreements (SLAs) zu messen und den zeitlichen Ablauf der Schadenbearbeitung zu verstehen.

Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle zeitbezogenen Kennzahlen wie Zykluszeiten und Engpässe zu berechnen.

Üblicherweise in Event Logs, Prüfprotokollen oder Transaktionsdaten erfasst, oft mit der Bezeichnung „Ereigniszeit“ oder „Erstellungsdatum“.

„Letzte Datenaktualisierung“ gibt an, wann die Daten des Event Logs zuletzt aus den Quellsystemen aktualisiert wurden. Dieser Timestamp zeigt, wie aktuell die analysierten Daten sind, und macht transparent, auf welchem Datenstand die Beteiligten arbeiten.

Für fundierte Entscheidungen in der Prozessanalyse ist es entscheidend zu wissen, wie aktuell die Daten sind. Anhand dieses Attributs erkennen Benutzer, ob sie einen Prozess nahezu in Echtzeit oder einen historischen Stand betrachten. Das ist besonders wichtig für Dashboards zur laufenden Überwachung und dafür, dass Schlussfolgerungen auf relevanten, aktuellen Informationen beruhen.

Zeigt, wie aktuell die Daten sind, und stellt sicher, dass Analysen und Entscheidungen auf dem neuesten Informationsstand beruhen.

Dabei handelt es sich üblicherweise um Metadaten, die während der Datenextraktion, -transformation und -ladung (ETL) erzeugt werden.

Das Attribut „Quellsystem“ bezeichnet die konkrete IT-Anwendung oder Plattform, in der die Aktivität ursprünglich erfasst wurde. In komplexen Umgebungen können Daten zur Schadenbearbeitung aus mehreren Systemen stammen, etwa aus einer zentralen Schadenplattform, einem Dokumentenmanagementsystem oder einem Customer-Relationship-Management-System (CRM).

Die Kenntnis des Quellsystems ist für die Datenvalidierung und die Analyse fragmentierter Prozesse hilfreich. Sie ermöglicht es, Probleme mit der Datenqualität bis zu ihrem Ursprung zurückzuverfolgen und Ineffizienzen aufzudecken, die durch manuelle Datenübertragungen oder Übergaben zwischen Systemen entstehen. Die Analyse kann Möglichkeiten für eine bessere Systemintegration und Automatisierung aufzeigen.

Gibt den Ursprung der Ereignisdaten an. Das ist entscheidend für die Datenvalidierung und die Analyse der Prozessausführung über mehrere IT-Systeme hinweg.

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

Das Attribut „Abteilung“ bezeichnet die Organisationseinheit, die in einer bestimmten Phase des Schadenverlaufs für den Schaden zuständig ist. Beispiele sind „Erste Schadenmeldung“, „Sondereinheit für Untersuchungen“ oder „Zahlungsabteilung“.

Diese Information ist wichtig, um Übergaben und die Zusammenarbeit zwischen verschiedenen Organisationseinheiten zu verstehen. Eine Analyse nach Abteilung kann Verzögerungen aufzeigen, die entstehen, wenn ein Schaden von einem Team an ein anderes übergeben wird. Sie hilft, abteilungsübergreifende Engpässe zu erkennen und die Arbeitslast sowie die Leistung einzelner Teams zu bewerten. Damit unterstützt sie Kennzahlen wie die ausgewogene Arbeitslast der Schadenregulierer und Dashboards zur Teamleistung.

Unterstützt die Analyse von Prozessübergaben zwischen Teams und die Erkennung abteilungsübergreifender Engpässe, um die Leistung der Organisation zu bewerten.

Üblicherweise im Schadendatensatz gespeichert und häufig dem zugewiesenen Benutzer oder der aktuellen Prozessphase zugeordnet.

Die Endzeit ist ein genauer Zeitstempel, der den Abschluss einer Aktivität festhält. Liegt sie zusammen mit einer Startzeit vor, lässt sich die Dauer der Aktivität exakt berechnen.

Dieses Attribut ist für eine detaillierte Leistungsanalyse besonders wertvoll. Die Differenz zwischen Start- und Endzeit ergibt die Verarbeitungszeit oder Aktivitätsdauer, eine wichtige Kennzahl zur Erkennung ineffizienter Prozessschritte. Die Analyse der Verarbeitungszeiten zeigt, welche Aktivitäten die meisten Ressourcen beanspruchen und wo Maßnahmen zur Prozessverbesserung ansetzen sollten. Sie ist eine wichtige Grundlage für Dashboards zu Prozessengpässen und Teamleistung.

Ermöglicht die genaue Berechnung der Verarbeitungszeiten von Aktivitäten. Das ist entscheidend, um Engpässe zu erkennen und die Ressourceneffizienz zu analysieren.

Üblicherweise zusammen mit der Startzeit in Event Logs oder Prüfprotokollen zu finden. Wenn nur Änderungsereignisse protokolliert werden, muss die Endzeit möglicherweise abgeleitet werden.

Der Regulierungsbetrag bezeichnet die gesamte Geldsumme, die zur Regulierung eines Schadens ausgezahlt wird. Als wichtige Ergebniskennzahl zeigt er die finanziellen Auswirkungen des Schadens. Üblicherweise wird der Betrag festgelegt, nachdem der Schaden bewertet und eine Entscheidung getroffen wurde.

Im Process Mining ist dieses Attribut für die Kostenanalyse entscheidend. Es ermöglicht die Berechnung von Kennzahlen wie „Durchschnittliche Kosten pro Schaden“ und zeigt, wie sich Prozessabweichungen auf die finanziellen Ergebnisse auswirken. So kann die Analyse beispielsweise ergeben, dass Schäden mit bestimmten Nachbearbeitungsschleifen oder längeren Zykluszeiten zu höheren Regulierungsbeträgen führen. Dadurch wird der Zusammenhang zwischen Prozesseffizienz und finanzieller Leistung sichtbar. Das Attribut bildet eine wichtige Grundlage für das Dashboard „Schadenkostenanalyse“.

Diese wichtige Ergebniskennzahl stellt den direkten Zusammenhang zwischen Prozessverhalten und finanziellen Auswirkungen her und ermöglicht eine Kosten-Nutzen-Analyse von Prozessverbesserungen.

Zu finden in den Finanz- oder Zahlungsdaten des Schadens. Der Betrag wird bei Abschluss des Schadens oder bei der Zahlung endgültig festgelegt.

Die Schadenart ordnet Schäden nach Geschäftsbereich oder Art des Schadens ein, zum Beispiel als „Kraftfahrzeug“, „Sachschaden“, „Haftpflicht“ oder „Berufsunfähigkeit“. Je nach Schadenart gelten oft unterschiedliche Prozessabläufe, Komplexitätsstufen und SLAs.

Die Prozessanalyse nach Schadenart ist eine grundlegende Methode, um aussagekräftige Erkenntnisse zu gewinnen. Sie ermöglicht den Vergleich von Zykluszeiten, Kosten und Prozesskonformität zwischen verschiedenen Kategorien. So kann sich beispielsweise zeigen, dass ein Prozess bei Kraftfahrzeugschäden effizient, bei Sachschäden jedoch ineffizient ist. Diese Erkenntnisse helfen, Verbesserungsmaßnahmen gezielt auszurichten. Das Attribut ist entscheidend für das Dashboard „Leistung nach Schadenkategorie“.

Ermöglicht die Aufschlüsselung von Schäden, um Prozesse und Leistung in verschiedenen Geschäftsbereichen zu vergleichen und Probleme einzelner Kategorien aufzudecken.

Ein Standardfeld im Hauptdatensatz des Schadens, das üblicherweise bei der Anlage des Schadens festgelegt wird.

Die Schadenschwere gibt Aufschluss über die Komplexität, Dringlichkeit oder möglichen Kosten eines Schadens. Diese Einstufung hilft dabei, Schäden zu priorisieren und Schadenregulierern mit den passenden Fachkenntnissen zuzuweisen. Die Einstufung kann sich beispielsweise nach der geschätzten Schadenhöhe, der Art des Vorfalls oder einem laufenden Rechtsstreit richten.

Die Analyse nach Schadenschwere ist entscheidend, um zu prüfen, ob die Bearbeitung angemessen auf den jeweiligen Schaden zugeschnitten ist. Bei Schäden mit hoher Schadenschwere sind beispielsweise längere Zykluszeiten zu erwarten, zugleich sollte die Untersuchung gründlicher ausfallen. Dieses Attribut hilft sicherzustellen, dass komplexe Schäden die nötige Aufmerksamkeit erhalten und einfache Schäden zügig bearbeitet werden. So lassen sich Ressourcen gezielter einsetzen und die Kundenzufriedenheit verbessern.

Hilft, einfache und komplexe Schäden zu unterscheiden und zu prüfen, ob die Prozessausführung der jeweiligen Komplexität angemessen ist.

Wird häufig bei der Schadenaufnahme anhand von Geschäftsregeln festgelegt und als Feld im Hauptdatensatz des Schadens gespeichert.

Das Zieldatum für die Schadenregulierung, auch Fälligkeitsdatum genannt, ist die Frist für den Abschluss der Schadenbearbeitung. Es ergibt sich häufig aus gesetzlichen Vorgaben oder internen Service Level Agreements (SLAs), die eine zeitnahe Betreuung der Kunden sicherstellen sollen.

Dieses Attribut ist eine wichtige Grundlage für die Compliance- und Leistungsüberwachung. Durch den Vergleich des tatsächlichen Abschlussdatums mit dem Zieldatum können Organisationen ihre SLA-Einhaltungsquote ermitteln. Process Mining zeigt, welche Prozessschritte oder Varianten besonders häufig zu SLA-Verstößen führen. So lassen sich Fristen vorausschauend steuern und Verbesserungen gezielt dort umsetzen, wo sie die größte Wirkung auf eine fristgerechte Regulierung haben. Das unterstützt direkt das Dashboard „Einhaltung von SLAs und Fristen“.

Ermöglicht die Messung der fristgerechten Bearbeitung anhand von SLAs oder gesetzlichen Fristen, einem wichtigen Maß für die Prozesseffektivität.

Wird üblicherweise bei der Anlage eines Schadens anhand von Geschäftsregeln berechnet und im Hauptdatensatz des Schadens gespeichert.

Der zugewiesene Schadenregulierer bezeichnet den Mitarbeitenden oder Benutzer, der eine bestimmte Aktivität ausgeführt hat oder zu einem bestimmten Zeitpunkt für den Schaden verantwortlich ist. Dieses Attribut ordnet Prozessschritte den ausführenden Mitarbeitenden zu.

Die Analyse nach Schadenregulierer ist wichtig für die Arbeitslaststeuerung, die Leistungsbewertung und die Ermittlung des Schulungsbedarfs. Führungskräfte können die Leistung im Team vergleichen, die Arbeit gleichmäßig verteilen und erkennen, wer besonders gute Ergebnisse erzielt oder zusätzliche Unterstützung benötigt. Diese Sicht auf die eingesetzten Ressourcen ist eine wichtige Grundlage für Dashboards zur Teamleistung und zur Verteilung der Arbeitslast.

Ordnet Prozessaktivitäten den ausführenden Personen zu und ermöglicht so die Analyse von Arbeitslast, Teamleistung und Ressourcenzuweisung.

Zu finden in Transaktionsdatensätzen, Prüfprotokollen oder Benutzerzuweisungsfeldern des Schadenmanagementsystems.

Der Ablehnungsgrund ist ein Code oder eine Textbeschreibung, die erläutert, warum ein Schaden nicht reguliert wurde. Gründe können eine fehlende Deckung durch die Police, betrügerische Aktivitäten oder nicht eingereichte erforderliche Unterlagen sein.

Die Analyse der Ablehnungsgründe ist wichtig, um Verbesserungsmöglichkeiten in internen Prozessen und in der Kundenkommunikation zu erkennen. Werden beispielsweise viele Schadenansprüche wegen fehlender Angaben abgelehnt, kann das auf Verbesserungsbedarf bei der Schadenaufnahme hindeuten. Eine Ursachenanalyse kann zu verständlicheren Versicherungsbedingungen, einer besseren Kundeninformation und weniger Verwaltungsaufwand für Schadenfälle führen, die letztlich abgelehnt werden.

Zeigt, warum Schadenansprüche nicht reguliert werden. So lassen sich Ursachen ermitteln und die Kundenkommunikation sowie die vorgelagerten Prozesse verbessern.

Wird bei der Aktivität „Schaden abgelehnt“ aus einer vorgegebenen Liste ausgewählt oder vom Sachbearbeiter als Text eingegeben.

Der Einreichungskanal gibt an, wie ein Schaden dem Unternehmen erstmals gemeldet wurde. Übliche Kanäle sind ein Online-Kundenportal, eine mobile App, ein Vermittler, ein Makler oder der Postweg.

Die Analyse nach Einreichungskanal kann wichtige Unterschiede bei Datenqualität, Effizienz und Customer Experience aufzeigen. Über ein digitales Portal eingereichte Schäden weisen beispielsweise möglicherweise weniger Eingabefehler auf und werden anfangs schneller bearbeitet als postalisch eingereichte Schäden. Diese Erkenntnisse unterstützen strategische Entscheidungen dazu, welche Kanäle stärker gefördert werden sollten und wo sich Investitionen in Automatisierung und Prozessverbesserung lohnen.

Hilft zu analysieren, wie sich der Eingangskanal auf Prozesseffizienz, Datenqualität und die gesamte Zykluszeit auswirkt.

Wird üblicherweise bei der ersten Schadenmeldung (FNOL) erfasst und im Hauptdatensatz des Schadens gespeichert.

Der geforderte Betrag ist die erste Schätzung des Schadens oder der Betrag, den der Anspruchsteller zu Beginn des Prozesses verlangt. Im Laufe der Prüfung und Bewertung kann sich dieser Wert noch ändern.

Dieses Attribut eignet sich für verschiedene Analysen. Es kann zur ersten Einschätzung der Schadenhöhe dienen und zeigt die Abweichung zwischen der ursprünglichen Forderung und der abschließenden Regulierungssumme. Die Analyse dieser Abweichung gibt Aufschluss über die Genauigkeit der ersten Schätzungen und die Wirksamkeit der Kostenkontrolle im Schadenprozess. Außerdem ist der Betrag eine wichtige Grundlage für Finanzprognosen und Rückstellungen.

Beziffert den anfänglichen finanziellen Umfang des Schadens. Der Wert eignet sich zur Einschätzung der Schadenhöhe und zum Vergleich mit der abschließenden Regulierungssumme.

Wird bei der ersten Schadenmeldung erfasst und im Finanzbereich des Schadendatensatzes gespeichert.

Das Schadendatum bezeichnet den tatsächlichen Tag des Ereignisses, etwa eines Autounfalls oder eines Sachschadens, das zur Schadenmeldung geführt hat. Es unterscheidet sich vom Datum, an dem der Schaden gemeldet oder im System erfasst wurde.

Die Zeitspanne zwischen dem Schadendatum und der Erfassung der Schadenmeldung wird als „Meldeverzug“ bezeichnet. Die Analyse dieses Zeitraums hilft, das Verhalten von Kunden besser zu verstehen und mögliche Betrugsrisiken zu erkennen, etwa bei ungewöhnlich langen Verzögerungen. Sie bildet den gesamten Verlauf vom Vorfall bis zum Abschluss ab und bietet damit einen umfassenderen Überblick als die reine interne Bearbeitungszeit.

Legt das Datum des tatsächlichen Vorfalls fest. So lassen sich Meldeverzögerungen und der gesamte Zeitraum vom Ereignis bis zum Abschluss analysieren.

Wird vom Anspruchsteller bei der „Erstmeldung des Schadens“ angegeben und im zentralen Schadendatensatz gespeichert.

Der Schadenstatus gibt den Stand des Schadens im Verlauf zum Zeitpunkt eines Ereignisses an. Er fasst zusammen, an welcher Stelle des Prozesses sich der Schaden befindet, zum Beispiel „In Untersuchung“, „Informationen ausstehend“ oder „Reguliert“.

Process Mining rekonstruiert den detaillierten Ablauf anhand der Aktivitäten. Das Attribut „Schadenstatus“ ergänzt diese Analyse um wertvollen Kontext. Es kann zur Validierung des Prozessablaufs dienen, etwa um zu prüfen, ob die Aktivität „Zahlung angewiesen“ den Status korrekt auf „Geschlossen“ setzt. Außerdem lässt sich damit analysieren, wie lange Schäden in bestimmten Status verbleiben. So wird sichtbar, wie lange Cases unbearbeitet bleiben und wo systematische Verzögerungen oder Ineffizienzen auftreten.

Zeigt den Status eines Schadens zu einem bestimmten Zeitpunkt. So lässt sich die Dauer in den einzelnen Phasen analysieren und der Prozessablauf überprüfen.

Ein zentrales Feld im Hauptdatensatz des Schadens, das im Verlauf der Schadenbearbeitung aktualisiert wird.

Die Versicherungsnummer ist die eindeutige Referenz für den Versicherungsvertrag, der den gemeldeten Schaden abdeckt. Sie ordnet den Schaden einem bestimmten Kunden, den Vertragsbedingungen, den Deckungssummen und weiteren Vertragsdetails zu.

Auch wenn die Versicherungsnummer nicht immer direkt in die Analyse des Prozessablaufs einfließt, ist sie eine wichtige Kontextinformation. Mit ihr lassen sich Schadendaten auf Ebene der Police oder des Kunden zusammenfassen. So werden beispielsweise Häufungen von Schadensmeldungen durch einzelne Versicherungsnehmer sichtbar. Außerdem können die Schadendaten um Informationen zur Police ergänzt werden, etwa um die Versicherungsart oder die Deckungssumme. Das ermöglicht eine differenziertere Segmentierung und Analyse.

Ordnet den Schaden dem jeweiligen Versicherungsvertrag zu. So lassen sich die Daten um Policeninformationen ergänzen und im passenden Kontext analysieren.

Eine grundlegende Information, die bei der Schadenmeldung erfasst und im Kopf des Schadendatensatzes gespeichert wird.