Datenvorlage: Schadenbearbeitung

Die Schadenfall-ID ist die zentrale Fallkennung, die alle Aktivitäten, Events und Datenpunkte eines Schadenfalls von der Meldung bis zum Abschluss verbindet.

Im Process Mining ist dieses Attribut essenziell, um den End-to-End-Verlauf jedes Falls zu rekonstruieren. Es ermöglicht, alle zugehörigen Events einem Fall zuzuordnen und so Durchlaufzeiten, Prozessvarianten und Engpässe auf Ebene einzelner Schadenfälle zu analysieren.

Das ist der zentrale Schlüssel zur Verfolgung des Claim-Lebenszyklus. Ohne eine eindeutige Claim-ID lassen sich die einzelnen Prozessschritte nicht zu einem stimmigen Prozessverlauf für die Analyse verbinden.

Dies ist in der Regel die 'CaseNumber' am Case-Objekt oder ein benutzerdefiniertes, eindeutiges ID-Feld am 'Claim'-Objekt (FinancialServicesCloud.Claim).

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

Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten hilft, die gängigsten Prozesspfade (Varianten) zu identifizieren, Abweichungen vom Standardprozess aufzudecken und wiederkehrende Aktivitäten zu erkennen, die auf Nacharbeit hindeuten.

Es beschreibt das 'Was' im Prozess, ermöglicht die Visualisierung des Prozessflusses und das Erkennen von Engpässen, Nacharbeitsschleifen und Prozessvarianten.

Abgeleitet aus Änderungen am Feld 'Status' des Objekts Claim/Case oder aus dem 'Betreff' zugehöriger Task- oder Event-Datensätze.

Event Time liefert das genaue Datum und die genaue Uhrzeit für jede Aktivität im Lebenszyklus eines Schadenfalls. Diese zeitlichen Daten sind unerlässlich, um Ereignisse chronologisch zu ordnen und Dauern zu berechnen.

In der Analyse werden Zeitstempel genutzt, um alle zeitbezogenen Kennzahlen zu ermitteln – von Durchlaufzeiten zwischen Aktivitäten über Wartezeiten bis zur gesamten Falldauer. Sie sind die Grundlage für eine dynamische Prozessanimation und zeigen, wann und wo Verzögerungen entstehen.

Dieses Attribut liefert das 'Wann' zu jedem Ereignis – Grundlage für Dauerberechnungen, Zeitreihenanalysen der Prozessleistung und das Erkennen zeitbasierter Engpässe.

Bei Statusänderungen ist dies das 'CreatedDate' aus der Feldhistorie des Objekts (z. B. CaseHistory). Bei Tasks ist es 'CompletedDateTime' oder 'CreatedDate'.

Dieses Attribut zeigt Datum und Uhrzeit des letzten Datenabrufs aus der Salesforce Financial Services Cloud und liefert Kontext zur Aktualität der analysierten Daten.

Für Dashboard-Nutzer ist das wichtig, um die Aktualität der Analyse einzuschätzen. Es hilft, Erwartungen zu steuern, und ist wichtig, um zu prüfen, dass Datenpipelines planmäßig laufen.

Gibt wichtigen Kontext zur Datenaktualität, damit Analysten und Fachbereiche wissen, wie aktuell die Prozesssicht ist.

Dieser Wert wird zum Zeitpunkt der Ausführung vom Extraktionstool bzw. ETL-Prozess erzeugt und im Datensatz vermerkt.

Dieses Attribut kennzeichnet die Quellanwendung bzw. -plattform, aus der die Daten extrahiert wurden. Für diesen Prozess lautet der Wert durchgängig 'Salesforce Financial Services Cloud'.

Auch wenn es konstant wirkt: Das Quellsystem explizit mitzuführen, ist Best Practice – besonders in Umgebungen, in denen Daten aus mehreren Systemen zusammengeführt werden. So bleibt die Herkunft klar nachvollziehbar und die Angabe unterstützt Data Governance und Validierung.

Bestätigt die Herkunft der Daten – essenziell für Data Governance, Fehlersuche und die Integration aus mehreren Enterprise-Systemen.

Dabei handelt es sich typischerweise um einen statischen Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut nennt die dem Schadenfall zugeordnete Business Unit bzw. Abteilung, z. B. 'Personal Lines', 'Commercial Auto' oder 'Special Investigations Unit'.

Die Analyse nach Abteilung zeigt Leistungsunterschiede zwischen Teams, macht die Verteilung der Arbeitslast sichtbar und deckt bereichsspezifische Prozessabweichungen oder Engpässe auf. Diese Dimension ist in Dashboards wie 'Claim SLA Compliance Overview' besonders hilfreich, um die Leistung der Bereiche der Organisation zu vergleichen.

Ermöglicht Leistungsvergleiche zwischen Bereichen, hilft Best Practices zu identifizieren und Ressourcen wirksamer zu verteilen.

Das kann ein benutzerdefiniertes Feld am Claim/Case-Objekt sein oder sich aus dem Profil bzw. der Rolle des zugewiesenen Benutzers im User-Objekt ableiten.

Dieses Attribut gibt an, wie ein Schadenfall erstmals gemeldet wurde – z. B. über Webportal, Mobile App, Telefon oder E‑Mail. Der Meldekanal beeinflusst häufig die Qualität der anfänglichen Angaben und die folgenden Bearbeitungsschritte.

Die Auswertung nach Meldekanal hilft, Nachfragemuster und die Effizienz verschiedener Annahmemethoden zu verstehen. Das Dashboard 'Claims Throughput & Volume' nutzt dieses Attribut, um im Zeitverlauf die Anzahl der Meldungen je Kanal zu verfolgen – eine wichtige Grundlage für Ressourcenplanung und Technologieinvestitionen.

Unterstützt die Bewertung der Effizienz verschiedener Eingangskanäle und zeigt, ob bestimmte Kanäle zu mehr Nacharbeit oder längeren Durchlaufzeiten führen.

Dies ist in der Regel ein benutzerdefiniertes Picklist-Feld am Claim/Case-Objekt, häufig mit 'Origin' oder 'Channel' benannt.

Das Attribut End Time erfasst den exakten Zeitpunkt, an dem eine Aktivität endet. Während die Start Time (EventTime) den Beginn markiert, liefert End Time die zweite Grenze, um die tatsächliche Bearbeitungsdauer einer Aktivität zu messen.

In der Analyse ermöglichen Start Time und End Time die präzise Berechnung von Bearbeitungszeiten und deren Abgrenzung von Wartezeiten zwischen Aktivitäten. Das ist grundlegend für Dashboards wie 'Process Step Duration Breakdown' und hilft, Ineffizienzen innerhalb einzelner Tasks aufzudecken – nicht nur dazwischen.

Ermöglicht die präzise Berechnung der aktiven Bearbeitungszeit je Aktivität – entscheidend, um wertschöpfende Zeit von Wartezeit zu trennen.

Abgeleitet aus Zeitstempeln. Beispiel: Wenn 'Initial Review Performed' durch eine Statusänderung ausgelöst wird, kann EndTime der Zeitstempel der nächsten Statusänderung sein.

Dieses Attribut steht für den zu Beginn gemeldeten Gesamtschaden bzw. Forderungsbetrag des Kunden. Er beeinflusst häufig die Komplexität, den Prüfaufwand und den gewählten Bearbeitungspfad.

Auswertungen nach Schadenhöhe offenbaren wichtige Muster: Höherwertige Fälle haben oft längere Durchlaufzeiten, mehr Schritte oder werden an Spezialteams geleitet. Das hilft, realistische SLAs zu setzen und finanzielle Rückstellungen zu prognostizieren.

Stellt jeden Fall in seinen finanziellen Kontext und ermöglicht Analysen, wie der Schadenwert Komplexität, Dauer und Ergebnis beeinflusst.

Dies wäre ein benutzerdefiniertes Währungsfeld am Claim-Objekt in der Financial Services Cloud, z. B. 'ClaimedAmount__c'.

Die Schadenart ist eine zentrale Dimension für die Segmentierung und Analyse der Schadenbearbeitung. Unterschiedliche Arten folgen oft abweichenden Abläufen, haben verschiedene Komplexitäten und unterliegen unterschiedlichen SLAs.

Durch Filtern oder Vergleichen nach Schadenart lassen sich typspezifische Engpässe erkennen, die Einhaltung gezielter SLAs bewerten und Prozessvarianten je Kategorie verstehen. Sie wird in Dashboards wie 'Claim SLA Compliance Overview' und 'Claim Rejection Reason Analysis' eingesetzt und liefert gezieltere Einblicke.

Ermöglicht die Segmentierung von Schadenfällen, um Prozesse zu vergleichen, typenspezifische Probleme zu identifizieren und Verbesserungsinitiativen gezielt auszusteuern.

Dies ist häufig das Standardfeld 'Type' oder ein benutzerdefiniertes Picklist-Feld (Auswahlliste) am Case- oder Claim-Objekt.

Der Schadenstatus zeigt auf einen Blick, wo der Schaden im Lebenszyklus steht – zum Beispiel 'New', 'Investigation', 'Pending Customer' oder 'Closed'. Er ist ein zentrales Attribut, um den aktuellen Prozesszustand zu verstehen.

Dieses Attribut wird in operativen Dashboards wie dem 'Open Claims Ageing Report' intensiv genutzt, um die aktuelle Arbeitslast zu visualisieren und Schadenfälle zu identifizieren, die zu lange in einem bestimmten Status feststecken. Die Analyse von Statuswechseln ist außerdem ein Kernelement, um die Aktivitäten im Prozessmodell zu definieren.

Bietet Echtzeit-Transparenz über den Status aktiver Schäden und hilft, Rückstände zu steuern sowie festgefahrene Fälle zu identifizieren.

Dies ist das Standardfeld 'Status' am Case- oder Claim-Objekt.

Dieses Attribut identifiziert den verantwortlichen Schadenregulierer – entweder für eine Aktivität oder den gesamten Case. Meist wird es aus dem Owner des Schadenfalls oder der Person abgeleitet, die eine bestimmte Aufgabe abgeschlossen hat.

Leistungsanalysen nach Schadenregulierer sind für die operative Steuerung zentral. Dashboards wie 'Adjuster Workload & Performance' nutzen dieses Attribut, um Schadenvolumen, aktive Cases und Durchlaufzeiten pro Person zu verfolgen, die Arbeitslast ausgewogen zu verteilen und Coaching-Bedarf zu erkennen.

Dieses Attribut ist unerlässlich, um Team- und Einzelleistung zu analysieren, Arbeitslasten zu steuern und Best Practices sowie Schulungsbedarf zu identifizieren.

Dies ist das Feld 'OwnerId' am Case- oder Claim-Objekt; es verweist auf das User-Objekt, um den Namen des Sachbearbeiters zu erhalten.

Wenn die endgültige Entscheidung zu einem Schadenfall 'Rejected' lautet, liefert dieses Attribut den zugrunde liegenden Grund, z. B. 'Not Covered by Policy', 'Fraud Suspected' oder 'Incomplete Information'.

Dies ist das zentrale Attribut für das 'Claim Rejection Reason Analysis'-Dashboard. Durch die Analyse der Häufigkeit verschiedener Ablehnungsgründe – häufig nach Schadenart oder Fachbereich segmentiert – lassen sich Ansatzpunkte erkennen, um das Underwriting zu verbessern, die Policensprache zu präzisieren oder die Informationsbeschaffung zu optimieren und so ungültige Einreichungen zu reduzieren.

Bietet direkten Einblick, warum Schäden abgelehnt werden – entscheidend, um Zeichnungsrichtlinien zu verbessern und unnötige Bearbeitung ungültiger Fälle zu vermeiden.

Dies ist in der Regel ein benutzerdefiniertes Picklist-Feld am Claim/Case-Objekt, das verpflichtend wird, wenn der Status auf 'Rejected' oder 'Closed - Denied' gesetzt wird.

Diese Kennzahl berechnet die Dauer eines einzelnen Prozessschritts – also die 'aktive' Bearbeitungszeit. Sie ergibt sich typischerweise aus der Differenz zwischen End Time und Start Time einer Aktivität.

Das ist eine grundlegende Kennzahl für die Engpassanalyse. Das 'Process Step Duration Breakdown' Dashboard nutzt diese Berechnung, um zu zeigen, welche Aktivitäten am meisten Zeit binden – und lenkt Verbesserungsmaßnahmen dorthin, wo sie den größten Effekt erzielen.

Quantifiziert die tatsächliche Bearbeitungszeit je Schritt und hilft, aktive Engpässe von reiner Wartezeit zu unterscheiden.

Berechnetes Feld: 'EndTime' minus 'EventTime' (StartTime). Diese Berechnung erfolgt im Process-Mining-Tool oder während der Datentransformation.

Dieses Attribut erfasst den tatsächlich an den Anspruchsteller gezahlten Betrag, wenn der Schadenfall abgeschlossen und reguliert ist. Er kann vom ursprünglich gemeldeten Betrag abweichen – etwa durch Bewertung, Selbstbehalte und Deckungsgrenzen.

Die Analyse der Auszahlungssumme, insbesondere im Vergleich zum ursprünglich beanspruchten Betrag, liefert Hinweise auf die Genauigkeit der Schadenbewertung und den Erfolg von Vergleichsverhandlungen. Eine zentrale Finanzkennzahl zur Beurteilung der Gesamtkosten von Schadenfällen.

Bezeichnet die endgültige finanzielle Auswirkung eines Schadenfalls – wichtig für Finanzanalysen, Rückstellungen und zur Überprüfung der Genauigkeit der ersten Schadeneinschätzung.

Dies wäre ein benutzerdefiniertes Währungsfeld am Claim-Objekt oder an einem verknüpften Payment-Objekt in der Financial Services Cloud.

Diese Kennzahl misst die gesamte End-to-End-Dauer eines Claims – von der ersten Einreichung bis zur endgültigen Schließung. Sie wird als Differenz zwischen dem Timestamp des allerletzten und des allerersten Events für eine Claim-ID berechnet.

Dies ist einer der wichtigsten KPIs für die Prozessleistung und steht im Fokus des KPI 'Average Claim Cycle Time' sowie des 'Claim End-to-End Cycle Time' Dashboards. Die Senkung dieses Werts ist häufig ein zentrales Ziel von Prozessverbesserungsprojekten.

Misst die End-to-End-Effizienz des Prozesses und ist ein zentraler Indikator für das Kundenerlebnis.

Berechnetes Feld: Zeitstempel des letzten Events minus Zeitstempel des ersten Events je 'ClaimId'. Wird vom Process-Mining-Tool berechnet.

Dieses Flag unterscheidet zwischen Aufgaben, die von Sachbearbeitern erledigt werden, und solchen, die durch automatisierte Workflows, Regeln oder Systemintegrationen laufen. Beispiel: Die initiale Schadenregistrierung kann vollständig automatisiert sein.

Die Analyse des Automatisierungsgrads ist zentral, um Prozesseffizienz zu bewerten. Sie zeigt, wie erfolgreich Automatisierungsinitiativen sind, welche Schritte sich als nächste Kandidaten eignen und wie sich Tempo und Konsistenz automatisierter gegenüber manuellen Tätigkeiten unterscheiden.

Unterscheidet zwischen menschlichen und systemgetriebenen Aktivitäten – entscheidend, um Wirkung und Effizienz von Automatisierung zu bewerten.

Dies wird üblicherweise abgeleitet: Ist der mit einem Event verknüpfte Benutzer ein generischer 'System'- oder 'Integration'-User, steht dieses Flag auf true.

Dieses Flag steht auf true, wenn ein Claim in eine frühere Prozessstufe zurückspringt. Ein klassisches Beispiel ist der Wechsel von 'Investigation Completed' zurück zu 'Additional Information Requested'. Die Logik zur Erkennung von Rework basiert auf Prozesswissen.

Dieses Attribut ist grundlegend für das 'Claims Rework Loop Analysis' Dashboard und den KPI 'Rework Rate'. Es ermöglicht, Häufigkeit und Auswirkungen von Nacharbeit direkt zu quantifizieren – Nacharbeit ist ein zentraler Treiber für Ineffizienzen, höhere Kosten und längere Durchlaufzeiten.

Markiert ineffiziente Prozessschleifen direkt, ermöglicht die einfache Quantifizierung von Nacharbeit und eine gezielte Ursachenanalyse.

Berechnetes Feld. Abgeleitet durch die Analyse der Aktivitätsreihenfolge je Fall. Beispiel: Folgt auf 'Activity A' 'Activity B' und anschließend erneut 'Activity A', ist das zweite 'A' Nacharbeit.

Die Kunden-ID verknüpft den Schadenfall mit der Person oder Organisation, die ihn eingereicht hat. In Salesforce ist dies typischerweise ein Lookup auf das Objekt Account oder Contact.

Dieses Attribut ermöglicht eine kundenzentrierte Sicht auf den Schadenprozess. Damit lassen sich Schadenhistorien je Kunde analysieren, häufige Schadenmelder identifizieren und Services personalisieren. Zudem ist es wichtig, um Schadendaten mit weiteren Kundendaten aus dem CRM zu verknüpfen – für einen ganzheitlichen Blick auf das Geschäft.

Ermöglicht eine kundenzentrierte Analyse: Verstehen Sie Schadenmuster je Kunde und messen Sie den Einfluss der Schadenbearbeitung auf die Kundenbeziehung.

Dies ist ein Lookup-Feld am Claim/Case-Objekt, das auf das Account- oder Contact-Objekt verweist (z. B. 'AccountId' oder 'ContactId').

Die Policennummer verknüpft den Schadenfall mit der aktiven Versicherungspolice des Kunden. Sie liefert wesentlichen Kontext zu Deckungsumfang, -grenzen und Historie des Versicherungsnehmers.

Auch wenn sie nicht immer ein primärer Treiber des Prozessflusses ist, handelt es sich um eine zentrale Kontextinformation. Damit lassen sich Schadendaten mit Policendaten verbinden – etwa um zu verstehen, ob bestimmte Policentypen häufiger oder komplexer reguliert werden.

Verknüpft den Schadenfall mit der zugrunde liegenden Police und ermöglicht Analysen zu Mustern bei bestimmten Policen oder Deckungsarten.

Dies wäre ein Lookup-Feld am Claim-Objekt, das auf das 'InsurancePolicy'-Objekt in der Financial Services Cloud verweist.

Das Schadeneintrittsdatum hält fest, wann das durch die Versicherung abgedeckte Ereignis stattgefunden hat. Es unterscheidet sich vom Datum der Schadenmeldung.

Dieses Attribut ist wichtig für Compliance und zur Analyse der Zeitspanne zwischen Ereignis und Meldung. Große Lücken können auf Probleme hindeuten oder eine andere Behandlung erfordern. Das Feld liefert wertvollen Kontext für die vollständige Zeitachse.

Hilft, die Zeitspanne zwischen Ereignis und Meldung zu analysieren – ein Faktor, der Ermittlung und Regulierung beeinflusst.

Dies wäre ein benutzerdefiniertes Datumsfeld am Claim-Objekt, z. B. 'DateOfLoss__c'.

Dieses Attribut ist ein kategorisches Ergebnis, typischerweise mit Werten wie 'Met' oder 'Breached'. Es wird ermittelt, indem das tatsächliche Abschlussdatum des Schadenfalls (der Zeitstempel der finalen Aktivität) mit dem 'SlaTargetDate' verglichen wird.

Es ist die Kernmetrik für den KPI 'SLA Adherence Rate' und das Dashboard 'Claim SLA Compliance Overview'. Damit erhält man eine klare, eindeutige Aussage zur Zielerreichung – essenziell für Compliance-Reporting und operative Steuerung.

Liefert einen klaren Indikator für die Zielerreichung bei Terminvorgaben – essenziell für Kundenzufriedenheit und regulatorische Compliance.

Berechnetes Feld: Wenn die 'EndTime' des letzten Events kleiner oder gleich 'SlaTargetDate' ist, dann 'Met', sonst 'Breached'. Diese Logik wird während der Datentransformation oder im Process-Mining-Tool angewendet.

Das SLA Target Date ist ein berechnetes oder manuell gesetztes Datum und markiert die Frist für die Schadenregulierung. Daran wird die Termintreue gemessen.

Dieses Attribut ist zentral, um die Leistung gegenüber Zusagen an Kunden oder Aufsichtsbehörden zu überwachen. Es bildet die Grundlage für den KPI 'SLA Adherence Rate' und das Dashboard 'Claim SLA Compliance Overview'. So lässt sich verfolgen, welcher Anteil der Schadenfälle fristgerecht abgeschlossen wird und bei welchen Schadentypen oder Abteilungen die Ziele verfehlt werden.

Definiert das Performanceziel für die Schadenabschlusszeit und ermöglicht die direkte Messung der SLA-Einhaltung.

Dies ist typischerweise ein benutzerdefiniertes Formel- oder Datumsfeld am Claim/Case-Objekt, berechnet anhand des Einreichungsdatums und des Claim-Typs.

Dieses Attribut liefert den geografischen Kontext zum Schadenfall, z. B. das Bundesland des Schadenorts oder das Land des Versicherungsnehmers. Die Daten können aus der Adresse des Versicherungsnehmers oder den Schadendetails abgeleitet werden.

Geografische Analysen zeigen regionale Muster bei Schadentypen, Häufigkeiten und Bearbeitungszeiten. Außerdem lassen sich damit Leistungen verschiedener Regionalbüros bewerten und die Einhaltung standortspezifischer Vorgaben sicherstellen.

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

In der Regel abgeleitet aus den Adressfeldern (z. B. 'BillingState', 'BillingCountry') des zugehörigen Account- oder Contact-Objekts.