Ihr Daten-Template für die Schadenbearbeitung

Die Claim-ID ist die zentrale Case-Kennung. Sie verknüpft alle Aktivitäten, Ereignisse und Datenpunkte eines einzelnen Versicherungsschadensfalls von der Einreichung bis zum Abschluss.

Im Process Mining ist dieses Attribut entscheidend, um den End-to-End-Verlauf jedes Schadenfalls zu rekonstruieren. Dadurch lassen sich alle zugehörigen Ereignisse zu einem zusammenhängenden Case bündeln und Durchlaufzeiten, Prozessvarianten sowie Engpässe einzelner Schadenfälle analysieren.

Dies ist der zentrale Schlüssel zur Nachverfolgung des Lebenszyklus eines Schadenfalls. Ohne eine eindeutige Claim-ID lassen sich die verschiedenen Prozessschritte nicht zu einem konsistenten Analyseverlauf verbinden.

Dabei handelt es sich üblicherweise um die „CaseNumber“ im Objekt „Case“ oder um ein benutzerdefiniertes eindeutiges ID-Feld im Objekt „Claim“ (FinancialServicesCloud.Claim).

Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Schadenprozess, beispielsweise „Claim Submitted“, „Initial Review Performed“ oder „Payment Issued“. Es bildet das Rückgrat der Prozesslandkarte.

Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten hilft, die häufigsten Prozesspfade, also Varianten, zu erkennen, Abweichungen vom Standardprozess aufzudecken und Aktivitäten zu identifizieren, die häufig wiederholt werden und damit auf Nacharbeit hinweisen.

Es definiert das „Was“ des Prozesses. Dadurch lassen sich der Prozessfluss visualisieren sowie Engpässe, Nacharbeitsschleifen und Prozessvarianten erkennen.

Abgeleitet aus Änderungen des Feldes „Status“ im Objekt „Claim“ oder „Case“ beziehungsweise aus dem Feld „Subject“ verknüpfter Task- oder Event-Datensätze.

Event Time liefert Datum und Uhrzeit jeder Aktivität im Lebenszyklus des Schadenfalls. Diese Zeitdaten sind erforderlich, um Ereignisse chronologisch zu ordnen und Zeitdauern zu berechnen.

In der Analyse dienen Timestamps zur Berechnung aller zeitbezogenen Kennzahlen, darunter Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und die gesamte Case-Dauer. Sie sind die Grundlage für eine dynamische Prozessanimation und helfen zu erkennen, wann und wo Verzögerungen auftreten.

Dieses Attribut liefert das „Wann“ jedes Ereignisses. Damit lassen sich Zeitdauern berechnen, die Prozessleistung im Zeitverlauf analysieren und zeitbezogene Engpässe erkennen.

Bei Statusänderungen handelt es sich um den „CreatedDate“ aus der Feldhistorie des Objekts, beispielsweise „CaseHistory“. Bei Tasks ist dies „CompletedDateTime“ oder „CreatedDate“.

Dieses Attribut gibt an, wann die Daten zuletzt aus Salesforce Financial Services Cloud abgerufen wurden. Es liefert Kontext zur Aktualität der analysierten Daten.

Für Benutzer von Dashboards ist diese Information wichtig, um den Aktualitätsgrad der Analyse einzuschätzen. Sie hilft, Erwartungen an die Aktualität der Daten zu steuern, und unterstützt die Prüfung, ob Datenpipelines planmäßig ausgeführt werden.

Liefert wichtigen Kontext zur Aktualität der Daten. So erkennen Analysten und Fachanwender, wie aktuell die Prozesssicht ist.

Dieser Wert wird vom Datenextraktionstool oder ETL-Prozess zum Ausführungszeitpunkt erzeugt und im Datensatz gespeichert.

Dieses Attribut gibt die Quellanwendung oder Plattform an, aus der die Daten extrahiert wurden. Für diesen Prozess lautet der Wert durchgehend „Salesforce Financial Services Cloud“.

Auch wenn der Wert konstant erscheint, entspricht die explizite Erfassung des Quellsystems einer bewährten Vorgehensweise, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. Sie schafft Klarheit über die Datenherkunft und unterstützt Data Governance sowie die Validierung.

Bestätigt die Datenherkunft. Das ist entscheidend für Data Governance, die Fehleranalyse und die Integration von Daten aus mehreren Unternehmenssystemen.

Dabei handelt es sich üblicherweise um einen statischen Wert, der während der Datenextraktion und -transformation zur Kennzeichnung der Herkunft des Datensatzes ergänzt wird.

Dieses Attribut gibt die dem Schadenfall zugewiesene Geschäftseinheit oder Abteilung an, beispielsweise „Personal Lines“, „Commercial Auto“ oder „Special Investigations Unit“.

Die Analyse des Prozesses nach Abteilung hilft, Leistungsunterschiede zwischen Teams zu erkennen, die Verteilung der Arbeitslast zu verstehen und abteilungsspezifische Prozessabweichungen oder Engpässe aufzudecken. Diese Dimension ist in Dashboards wie „Claim SLA Compliance Overview“ hilfreich, um die Leistung verschiedener Organisationseinheiten zu vergleichen.

Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten. Dadurch lassen sich Best Practices erkennen und Ressourcen gezielter einsetzen.

Dies kann ein benutzerdefiniertes Feld im Objekt „Claim“ oder „Case“ sein oder aus dem Profil beziehungsweise der Rolle des zugewiesenen Benutzers im Objekt „User“ abgeleitet werden.

Dieses Attribut gibt an, wie ein Schadenfall erstmals gemeldet wurde, beispielsweise über ein Webportal, eine mobile App, telefonisch oder per E-Mail. Der Einreichungskanal kann die Qualität der ersten Informationen und die nachfolgenden Bearbeitungsschritte deutlich beeinflussen.

Die Analyse von Schadenfällen nach Einreichungskanal hilft, Nachfragemuster und die Effizienz verschiedener Aufnahmewege zu verstehen. Das Dashboard „Claims Throughput & Volume“ verwendet dieses Attribut, um das Schadenvolumen je Kanal im Zeitverlauf zu verfolgen. Die Ergebnisse können in Entscheidungen zur Ressourcenverteilung und zu Technologieinvestitionen einfließen.

Hilft, die Effizienz verschiedener Aufnahmewege zu bewerten und zu erkennen, ob bestimmte Kanäle zu mehr Nacharbeit oder längeren Durchlaufzeiten führen.

Dies ist üblicherweise ein benutzerdefiniertes Auswahllistenfeld im Objekt „Claim“ oder „Case“, häufig mit der Bezeichnung „Origin“ oder „Channel“.

Das Attribut End Time erfasst den exakten Zeitpunkt, an dem eine Aktivität endet. Während Start Time (EventTime) den Beginn markiert, liefert End Time die zweite Grenze zur Messung der Bearbeitungsdauer.

Wenn sowohl Start Time als auch End Time vorliegen, lassen sich Bearbeitungszeiten präzise berechnen und von Wartezeiten zwischen Aktivitäten unterscheiden. Dies ist die Grundlage für Dashboards wie „Process Step Duration Breakdown“ und hilft, Ineffizienzen innerhalb einzelner Tasks statt nur zwischen ihnen zu erkennen.

Ermöglicht die präzise Berechnung der aktiven Bearbeitungszeit jeder Aktivität. Das ist entscheidend, um wertschöpfende Zeit von Wartezeit zu unterscheiden.

Abgeleitet aus Timestamp-Daten. Wird „Initial Review Performed“ beispielsweise durch eine Statusänderung ausgelöst, kann EndTime dem Timestamp der nächsten Statusänderung entsprechen.

Dieses Attribut bezeichnet den gesamten Verlust- oder Schadensbetrag, den der Kunde zu Beginn des Prozesses geltend macht. Der Wert beeinflusst häufig die Komplexität des Schadenfalls, den erforderlichen Prüfaufwand und den weiteren Bearbeitungspfad.

Die Analyse von Prozesskennzahlen nach Schadenwert kann wichtige Muster sichtbar machen. Schadenfälle mit höheren Beträgen weisen beispielsweise längere Durchlaufzeiten auf, umfassen mehr Schritte oder werden an spezialisierte Teams weitergeleitet. Dies unterstützt die Festlegung realistischer SLAs und die Prognose finanzieller Rückstellungen.

Liefert den finanziellen Kontext jedes Cases und ermöglicht die Analyse, wie sich der Schadenwert auf Prozesskomplexität, Dauer und Ergebnisse auswirkt.

Dies wäre ein benutzerdefiniertes Währungsfeld im Objekt „Claim“ in Financial Services Cloud, beispielsweise „ClaimedAmount__c“.

Claim Type ist eine wichtige Dimension zur Segmentierung und Analyse des Schadenprozesses. Unterschiedliche Schadenarten folgen häufig eigenen Prozessen, weisen unterschiedliche Komplexitätsgrade auf und unterliegen verschiedenen SLAs.

Durch das Filtern oder Vergleichen der Leistung nach Claim Type können Analysten schadenartspezifische Engpässe aufdecken, die Einhaltung gezielter SLAs bewerten und Unterschiede zwischen Prozessvarianten verstehen. Das Attribut wird in Dashboards wie „Claim SLA Compliance Overview“ und „Claim Rejection Reason Analysis“ für gezieltere Erkenntnisse verwendet.

Ermöglicht die Segmentierung von Schadenfällen, den Prozessvergleich, die Erkennung schadenartspezifischer Probleme und die gezielte Planung von Verbesserungsmaßnahmen.

Dabei handelt es sich häufig um das Standardfeld „Type“ oder ein benutzerdefiniertes Auswahllistenfeld im Objekt „Case“ oder „Claim“.

Claim Status zeigt, an welcher Stelle des Lebenszyklus sich der Schadenfall befindet, beispielsweise „New“, „Investigation“, „Pending Customer“ oder „Closed“. Es ist ein zentrales Attribut, um den aktuellen Prozessstatus zu verstehen.

Dieses Attribut wird intensiv in operativen Dashboards wie dem „Open Claims Ageing Report“ verwendet, um die aktuelle Arbeitslast sichtbar zu machen und Schadenfälle zu erkennen, die zu lange in einem bestimmten Status verbleiben. Die Analyse von Statusübergängen ist außerdem eine zentrale Methode zur Definition der Aktivitäten in der Prozesslandkarte.

Schafft aktuelle Transparenz über den Status aktiver Schadenfälle. Dadurch lassen sich Rückstände steuern und stagnierende Cases erkennen.

Dies ist das Standardfeld „Status“ im Objekt „Case“ oder „Claim“.

Dieses Attribut identifiziert den zuständigen Schadenregulierer für eine Aktivität oder den gesamten Case. Es wird üblicherweise aus dem Eigentümer des Schaden-Case oder der Person abgeleitet, die einen bestimmten Task abgeschlossen hat.

Die Analyse der Leistung nach Schadenregulierer ist für die operative Steuerung entscheidend. Dashboards wie „Adjuster Workload & Performance“ verwenden dieses Attribut, um Schadenvolumen, aktive Cases und Durchlaufzeiten je Person zu verfolgen. So lassen sich Arbeitslasten ausgewogen verteilen und Coaching-Bedarfe erkennen.

Dieses Attribut ist wichtig, um die Leistung von Teams und Einzelpersonen zu analysieren, Arbeitslasten zu steuern sowie Best Practices und Schulungsbedarf zu erkennen.

Dies ist das Feld „OwnerId“ im Objekt „Case“ oder „Claim“. Es verweist auf das Objekt „User“, um den Namen des Schadenregulierers abzurufen.

Wenn die endgültige Entscheidung für einen Schadenfall „Rejected“ lautet, gibt dieses Attribut den zugrunde liegenden Grund an, beispielsweise „Not Covered by Policy“, „Fraud Suspected“ oder „Incomplete Information“.

Dies ist das zentrale Attribut für das Dashboard „Claim Rejection Reason Analysis“. Durch die Analyse der Häufigkeit verschiedener Ablehnungsgründe, häufig segmentiert nach Schadenart oder Abteilung, kann die Organisation Verbesserungsmöglichkeiten bei der Risikoprüfung, der Formulierung von Policen oder der Informationsbeschaffung erkennen und so ungültige Einreichungen reduzieren.

Liefert direkte Erkenntnisse darüber, warum Schadenfälle abgelehnt werden. Das ist entscheidend, um Richtlinien zur Risikoprüfung zu verbessern und die aufwendige Bearbeitung ungültiger Schadenfälle zu reduzieren.

Dies ist üblicherweise ein benutzerdefiniertes Auswahllistenfeld im Objekt „Claim“ oder „Case“, das bei einer Statusänderung in „Rejected“ oder „Closed - Denied“ verpflichtend wird.

Diese Kennzahl misst die gesamte End-to-End-Dauer eines Schaden-Case, von der ersten Einreichung bis zum endgültigen Abschluss. Sie wird als Differenz zwischen dem Timestamp des letzten und des ersten Ereignisses einer bestimmten Claim-ID berechnet.

Dies ist eine der wichtigsten KPIs für die Prozessleistung. Sie wird direkt durch die KPI „Average Claim Cycle Time“ und das Dashboard „Claim End-to-End Cycle Time“ abgebildet. Die Reduzierung dieses Werts ist häufig ein zentrales Ziel von Prozessverbesserungsprojekten.

Misst die gesamte End-to-End-Effizienz des Prozesses und ist ein wichtiger Indikator für die Customer Experience.

Berechnetes Feld: Timestamp des letzten Ereignisses minus Timestamp des ersten Ereignisses je „ClaimId“. Die Berechnung erfolgt durch das Process-Mining-Tool.

Dieses Kennzeichen unterscheidet Tasks, die von menschlichen Schadenregulierern abgeschlossen wurden, von Aktivitäten automatisierter Workflows, Regeln oder Systemintegrationen. So kann beispielsweise die erste Erfassung eines Schadenfalls vollständig automatisiert erfolgen.

Die Analyse des Automatisierungsgrads ist entscheidend, um die Prozesseffizienz zu verstehen. Sie hilft, den Erfolg von Automatisierungsinitiativen zu messen, geeignete Schritte für eine weitere Automatisierung zu erkennen und Geschwindigkeit sowie Konsistenz automatisierter und manueller Tasks zu vergleichen.

Unterscheidet zwischen menschlichen und systemgesteuerten Aktivitäten. Das ist entscheidend, um die Auswirkungen und Wirksamkeit der Automatisierung zu bewerten.

Dieses Attribut wird üblicherweise abgeleitet. Ist der mit einem Ereignis verknüpfte Benutzer ein generischer „System“- oder „Integration“-Benutzer, wird dieses Kennzeichen auf true gesetzt.

Dieses Kennzeichen wird auf „true“ gesetzt, wenn ein Claim zu einer früheren Prozessstufe zurückkehrt. Ein klassisches Beispiel ist der Wechsel von „Investigation Completed“ zurück zu „Additional Information Requested“. Die Logik zur Erkennung von Nacharbeit wird auf Grundlage des Prozesswissens definiert.

Dieses Attribut ist grundlegend für das Dashboard „Claims Rework Loop Analysis“ und die KPI „Rework Rate“. Es ermöglicht eine direkte Quantifizierung der Häufigkeit und Auswirkungen von Nacharbeit, die maßgeblich zu Ineffizienz, höheren Kosten und längeren Durchlaufzeiten beiträgt.

Kennzeichnet ineffiziente Prozessschleifen direkt und ermöglicht dadurch eine einfache Quantifizierung der Nacharbeit sowie eine gezielte Analyse ihrer Ursachen.

Berechnetes Feld. Es wird durch die Analyse der Aktivitätsabfolge für jeden Case abgeleitet. Folgt beispielsweise auf „Activity A“ zunächst „Activity B“ und anschließend erneut „Activity A“, gilt die zweite Instanz von „A“ als Nacharbeit.

Die Customer ID verknüpft den Schadenfall mit der Person oder Organisation, die ihn eingereicht hat. In Salesforce handelt es sich dabei üblicherweise um einen Lookup auf das Objekt „Account“ oder „Contact“.

Dieses Attribut ermöglicht eine kundenorientierte Sicht auf den Schadenprozess. Es kann verwendet werden, um die Schadenhistorie je Kunde zu analysieren, Kunden mit häufigen Schadenmeldungen zu erkennen und den Service individueller auszurichten. Außerdem ist es wichtig, um Schadendaten mit weiteren Kundendaten aus einem CRM zu verbinden und so eine umfassende Geschäftssicht zu schaffen.

Ermöglicht eine kundenorientierte Analyse. Dadurch lassen sich Schadenmuster einzelner Kunden verstehen und die Auswirkungen des Schadenprozesses auf Kundenbeziehungen messen.

Dies ist ein Lookup-Feld im Objekt „Claim“ oder „Case“, das auf das Objekt „Account“ oder „Contact“ verweist, beispielsweise über „AccountId“ oder „ContactId“.

Dieses Attribut liefert den geografischen Kontext des Schadenfalls, beispielsweise den Bundesstaat, in dem der Schaden eingetreten ist, oder das Land des Versicherungsnehmers. Die Daten können aus der Adresse des Versicherungsnehmers oder aus den Angaben zum Schaden abgeleitet werden.

Die geografische Analyse kann regionale Trends bei Schadenarten, Häufigkeiten und Bearbeitungszeiten sichtbar machen. Außerdem lässt sich die Leistung verschiedener Regionalbüros vergleichen und die Einhaltung ortsspezifischer Vorschriften prüfen.

Ermöglicht die geografische Analyse von Schadenfällen und kann regionale Leistungsunterschiede, Betrugsmuster oder Auswirkungen lokaler Ereignisse sichtbar machen.

Üblicherweise abgeleitet aus den Adressfeldern, beispielsweise „BillingState“ oder „BillingCountry“, im verknüpften Objekt „Account“ oder „Contact“.

Loss Date erfasst, wann das von der Versicherungspolice gedeckte Ereignis eingetreten ist. Dieses Datum unterscheidet sich vom Datum der Schadenmeldung.

Das Attribut ist für Compliance und die Analyse der Zeitspanne zwischen Vorfall und Meldung wichtig. Größere Abstände können auf mögliche Probleme hinweisen oder eine abweichende Bearbeitung erfordern. Zudem liefert das Datum wichtigen Kontext für die vollständige zeitliche Abfolge der Ereignisse.

Hilft, die Zeitspanne zwischen einem Vorfall und seiner Meldung zu analysieren, die Untersuchung und Vergleich beeinflussen kann.

Dies wäre ein benutzerdefiniertes Datumsfeld im Objekt „Claim“, beispielsweise „DateOfLoss__c“.

Dieses Attribut beschreibt ein kategorisches Ergebnis, üblicherweise mit Werten wie „Met“ oder „Breached“. Es wird durch den Vergleich des tatsächlichen Abschlussdatums des Schadenfalls, also des Timestamps der letzten Aktivität, mit dem „SlaTargetDate“ abgeleitet.

Dies ist die zentrale Kennzahl für die KPI „SLA Adherence Rate“ und das Dashboard „Claim SLA Compliance Overview“. Sie liefert eine eindeutige Bewertung der Leistung im Verhältnis zu den Zielvorgaben und ist für Compliance-Berichte sowie die operative Steuerung entscheidend.

Liefert eine klare Kennzahl für die Einhaltung von Zeitvorgaben und ist damit entscheidend für Kundenzufriedenheit und Compliance.

Berechnetes Feld: Wenn „EndTime“ des letzten Events kleiner oder gleich „SlaTargetDate“ ist, dann „Met“, andernfalls „Breached“. Diese Logik wird während der Datentransformation oder innerhalb des Process-Mining-Tools angewendet.

Das SLA Target Date ist ein berechnetes oder manuell festgelegtes Datum und bezeichnet die Frist für den Abschluss des Schadenfalls. Es dient als Maßstab für die Bewertung der Termintreue.

Dieses Attribut ist entscheidend, um die Leistung anhand von Zusagen gegenüber Kunden oder Aufsichtsbehörden zu überwachen. Es bildet die Grundlage für die KPI „SLA Adherence Rate“ und das Dashboard „Claim SLA Compliance Overview“. Damit kann die Organisation verfolgen, welcher Anteil der Schadenfälle fristgerecht abgeschlossen wird, und erkennen, welche Schadenarten oder Abteilungen ihre Ziele nicht erreichen.

Definiert das Leistungsziel für die Bearbeitungszeit eines Schadenfalls und ermöglicht die direkte Messung der SLA-Konformität.

Dies ist üblicherweise ein benutzerdefiniertes Formel- oder Datumsfeld im Objekt „Claim“ oder „Case“, das auf Grundlage des Einreichungsdatums und der Schadenart berechnet wird.

Dieses Attribut erfasst den tatsächlich an den Anspruchsteller gezahlten Betrag, wenn der Schadenfall geschlossen und reguliert wird. Er kann aufgrund der Bewertung, Selbstbeteiligungen und Policenlimits vom ursprünglich geltend gemachten Betrag abweichen.

Die Analyse des Vergleichsbetrags, insbesondere im Verhältnis zum ursprünglich geltend gemachten Betrag, liefert Erkenntnisse zur Genauigkeit der Schadensbewertung und zu den Ergebnissen der Vergleichsverhandlungen. Er ist eine zentrale Finanzkennzahl zur Bestimmung der Gesamtkosten von Schadenfällen.

Bezeichnet die endgültigen finanziellen Auswirkungen eines Schadenfalls und ist für Finanzanalysen, Rückstellungen und die Bewertung der Genauigkeit erster Schadenschätzungen entscheidend.

Dies wäre ein benutzerdefiniertes Währungsfeld im Objekt „Claim“ oder in einem verknüpften Zahlungsobjekt in Financial Services Cloud.

Die Policy Number verknüpft den Schadenfall mit der aktiven Versicherungspolice des Kunden. Dadurch stehen wichtige Informationen zu Deckung, Limits und zur Historie des Versicherungsnehmers zur Verfügung.

Auch wenn sie den Prozessfluss nicht immer direkt bestimmt, ist sie ein wichtiges Kontextdatum. Sie kann verwendet werden, um Schaden- und Policendaten für vertiefte Analysen zu verbinden, beispielsweise um zu prüfen, ob bestimmte Policenarten mit häufigeren oder komplexeren Schadenfällen verbunden sind.

Verknüpft den Schadenfall mit der zugrunde liegenden Versicherungspolice und ermöglicht eine umfassendere Analyse von Schadenmustern im Zusammenhang mit bestimmten Policen oder Deckungsarten.

Dies wäre ein Lookup-Feld im Objekt „Claim“, das auf das Objekt „InsurancePolicy“ in Financial Services Cloud verweist.