Ihr Daten-Template für die Schadenbearbeitung

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

Im Process Mining ist dieses Attribut entscheidend, um den durchgängigen Verlauf jedes Versicherungsfalls zu rekonstruieren. Es führt alle zugehörigen Ereignisse zu einem zusammenhängenden Case zusammen und ermöglicht so die Analyse von Zykluszeiten, Prozessvarianten und Engpässen für einzelne Schadensfälle.

Dieses Attribut ist der zentrale Schlüssel, um den gesamten Verlauf eines Schadensfalls nachzuverfolgen. Ohne eine eindeutige Claim-ID lassen sich die verschiedenen Prozessschritte nicht zu einem zusammenhängenden Ablauf für die Analyse verknüpfen.

In der Regel ist dies das Feld 'CaseNumber' am Objekt Case oder ein benutzerdefiniertes Feld mit eindeutiger ID am Objekt 'Claim' (FinancialServicesCloud.Claim).

Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Schadenbearbeitungsprozess, etwa 'Schadensfall eingereicht', 'Erste Prüfung durchgeführt' oder 'Zahlung ausgeführt'. Es bildet das Grundgerüst der Prozessübersicht.

Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten hilft dabei, die häufigsten Prozesspfade (Varianten) zu erkennen, Abweichungen vom Standardprozess aufzudecken und häufig wiederholte Aktivitäten zu identifizieren, die auf Nacharbeit hindeuten.

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

Abgeleitet aus Änderungen des Felds 'Status' am Objekt Claim/Case oder aus dem Feld 'Subject' zugehöriger Task- oder Event-Einträge.

Die Ereigniszeit gibt für jede Aktivität im Verlauf des Schadensfalls das genaue Datum und die genaue Uhrzeit an. Diese Zeitangaben sind erforderlich, um Ereignisse chronologisch zu ordnen und Zeitspannen zu berechnen.

In der Analyse dienen Timestamps zur Berechnung aller zeitbezogenen Kennzahlen, darunter Zykluszeiten zwischen Aktivitäten, Wartezeiten und die Gesamtdauer eines Case. Sie sind außerdem die Grundlage für eine dynamische Prozessanimation und helfen dabei, Verzögerungen zeitlich und im Prozessablauf zu lokalisieren.

Dieses Attribut gibt für jedes Ereignis das 'Wann' an. So lassen sich Zeitspannen berechnen, die Prozessleistung im Zeitverlauf analysieren und zeitbedingte Engpässe erkennen.

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

Dieses Attribut gibt an, wann die Daten zuletzt aus Salesforce Financial Services Cloud abgerufen wurden. Es zeigt, wie aktuell die analysierten Daten sind.

Für Benutzer des Dashboards ist diese Information wichtig, um die Aktualität der Analyse einzuschätzen. Sie hilft dabei, Erwartungen an die Aktualität der Daten zu steuern und zu prüfen, ob die Datenpipelines planmäßig ausgeführt werden.

Gibt wichtige Hinweise zur Aktualität der Daten, damit Analysten und Fachanwender wissen, wie aktuell die Prozessansicht ist.

Dieser Wert wird zum Ausführungszeitpunkt vom Datenextraktionstool oder ETL-Prozess erzeugt und dem Datensatz hinzugefügt.

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 zu sein scheint, empfiehlt es sich, das Quellsystem ausdrücklich zu erfassen, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. So bleibt die Herkunft der Daten nachvollziehbar. Das ist für Data Governance und Validierungen hilfreich.

Bestätigt die Herkunft der Daten. Das ist wichtig für Data Governance, die Fehlerbehebung und die Integration von Daten aus mehreren Unternehmenssystemen.

In der Regel wird dieser statische Wert während der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut gibt die Geschäftseinheit oder Abteilung an, der der Schadensfall zugewiesen ist, zum Beispiel 'Privatkundengeschäft', 'Gewerbliche Kfz-Versicherung' oder 'Sonderermittlungseinheit'.

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 'Überblick zur SLA-Einhaltung bei Schadensfällen' hilfreich, um die Leistung verschiedener Organisationseinheiten zu vergleichen.

Ermöglicht den Leistungsvergleich zwischen verschiedenen Geschäftseinheiten. So lassen sich bewährte Vorgehensweisen erkennen und Ressourcen gezielter zuweisen.

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

Dieses Attribut gibt an, wie ein Schadensfall erstmals gemeldet wurde, zum Beispiel über ein Webportal, eine mobile App, telefonisch oder per E-Mail. Der Einreichungskanal kann die Qualität der ersten Angaben und die folgenden Bearbeitungsschritte erheblich beeinflussen.

Die Analyse nach Einreichungskanal hilft, Nachfragemuster und die Effizienz verschiedener Erfassungsmethoden zu verstehen. Das Dashboard 'Durchsatz und Volumen der Schadensfälle' verwendet dieses Attribut, um die Anzahl der Schadensfälle je Kanal im Zeitverlauf zu erfassen. Die Ergebnisse können in die Ressourcenplanung und in Entscheidungen zu Technologieinvestitionen einfließen.

Hilft, die Effizienz verschiedener Erfassungskanäle zu bewerten und festzustellen, ob bestimmte Kanäle häufiger zu Nacharbeit oder längeren Zykluszeiten führen.

Dies ist üblicherweise ein benutzerdefiniertes Auswahllistenfeld am Objekt Claim/Case, oft mit der Bezeichnung 'Origin' oder 'Channel'.

Das Attribut Endzeit erfasst den genauen Zeitpunkt, zu dem eine Aktivität endet. Die Startzeit (EventTime) markiert den Beginn. Die Endzeit bildet die zweite Grenze, die erforderlich ist, um die Dauer einer Aktivität zu messen.

Wenn sowohl Startzeit als auch Endzeit vorliegen, lassen sich die Verarbeitungszeiten der Aktivitäten genau berechnen und von den Wartezeiten zwischen Aktivitäten unterscheiden. Das ist eine wichtige Grundlage für Dashboards wie 'Dauer der Prozessschritte im Überblick' und hilft, Ineffizienzen in einzelnen Tasks statt nur zwischen ihnen zu erkennen.

Ermöglicht die genaue Berechnung der aktiven Verarbeitungszeit jeder Aktivität. So lässt sich die wertschöpfende Zeit von der Wartezeit unterscheiden.

Aus Timestamp-Daten abgeleitet. Wird beispielsweise 'Erste Prüfung durchgeführt' durch eine Statusänderung ausgelöst, kann als EndTime der Timestamp der nächsten Statusänderung dienen.

Dieses Attribut gibt den gesamten Schadenbetrag an, den der Kunde zu Beginn des Prozesses geltend macht. Der Wert beeinflusst häufig die Komplexität des Schadensfalls, den erforderlichen Prüfungsaufwand und den weiteren Bearbeitungsweg.

Die Analyse von Prozesskennzahlen nach Schadenshöhe kann wichtige Muster aufdecken. Schadensfälle mit höheren Beträgen können beispielsweise längere Zykluszeiten haben, mehr Schritte umfassen oder an spezialisierte Teams weitergeleitet werden. Diese Erkenntnisse helfen dabei, realistische SLAs festzulegen und finanzielle Rückstellungen zu prognostizieren.

Liefert den finanziellen Kontext zu jedem Case und ermöglicht die Analyse, wie sich die Schadenshöhe auf Prozesskomplexität, Dauer und Ergebnis auswirkt.

Dies wäre ein benutzerdefiniertes Währungsfeld am Objekt Claim in Financial Services Cloud, zum Beispiel 'ClaimedAmount__c'.

Die Schadensfallart ist eine wichtige Dimension, um den Schadenbearbeitungsprozess zu segmentieren und zu analysieren. Je nach Art des Schadensfalls unterscheiden sich die Abläufe, die Komplexität und die geltenden SLAs.

Durch Filter oder Leistungsvergleiche nach Schadensfallart können Analysten spezifische Engpässe erkennen, die Einhaltung der jeweiligen SLAs bewerten und Unterschiede zwischen Prozessvarianten nachvollziehen. Dieses Attribut wird in Dashboards wie 'Überblick zur SLA-Einhaltung bei Schadensfällen' und 'Analyse der Ablehnungsgründe' verwendet, um gezieltere Erkenntnisse zu gewinnen.

Ermöglicht die Segmentierung von Schadensfällen, um Prozesse zu vergleichen, spezifische Probleme zu erkennen und Verbesserungsmaßnahmen gezielt auszurichten.

Dies ist häufig ein Standardfeld 'Type' oder ein benutzerdefiniertes Auswahllistenfeld am Objekt Case oder Claim.

Der Schadensfallstatus zeigt den aktuellen Stand des Schadensfalls, etwa 'Neu', 'Untersuchung', 'Kunde ausstehend' oder 'Geschlossen'. Er ist ein wichtiges Attribut, um den aktuellen Prozessstatus zu verstehen.

Dieses Attribut wird häufig in operativen Dashboards wie dem 'Bericht zu offenen Schadensfällen nach Alter' verwendet. Damit lässt sich die aktuelle Arbeitslast visualisieren und erkennen, welche Schadensfälle zu lange in einem bestimmten Status verbleiben. Auch die Analyse von Statusübergängen ist eine wichtige Methode, um die Aktivitäten in der Prozessübersicht zu definieren.

Ermöglicht einen aktuellen Überblick über den Status offener Schadensfälle. So lassen sich Rückstände steuern und festgefahrene Cases erkennen.

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

Dieses Attribut bezeichnet die Schadensbearbeitung, die für eine Aktivität oder den gesamten Case zuständig ist. Es wird üblicherweise aus dem Eigentümer des Schadensfalls oder aus der Person abgeleitet, die einen bestimmten Task abgeschlossen hat.

Die Analyse der Leistung nach Schadensbearbeitung ist für die operative Steuerung wichtig. Dashboards wie 'Arbeitslast und Leistung der Schadensbearbeitung' verwenden dieses Attribut, um Fallzahlen, aktive Cases und Zykluszeiten pro Person zu erfassen. So lässt sich die Arbeitslast ausgewogen verteilen und gezielter ermitteln, wo Coaching sinnvoll ist.

Dieses Attribut ist wichtig, um die Leistung von Teams und einzelnen Mitarbeitenden zu analysieren, Arbeitslasten zu steuern und bewährte Vorgehensweisen oder Schulungsbedarf zu erkennen.

Dies ist das Feld 'OwnerId' am Objekt Case oder Claim. Es verweist auf das Objekt User, aus dem der Name der Schadensbearbeitung abgerufen wird.

Wenn die endgültige Entscheidung zu einem Schadensfall 'Rejected' lautet, gibt dieses Attribut den Grund an, zum Beispiel 'Nicht durch die Police abgedeckt', 'Betrugsverdacht' oder 'Unvollständige Angaben'.

Dieses Attribut ist die Grundlage für das Dashboard 'Analyse der Ablehnungsgründe'. Durch die Analyse der Häufigkeit verschiedener Ablehnungsgründe, aufgeschlüsselt nach Schadensfallart oder Abteilung, kann das Unternehmen Verbesserungsmöglichkeiten bei der Risikoprüfung erkennen, Policen verständlicher formulieren oder die Informationsbeschaffung verbessern, um ungültige Einreichungen zu reduzieren.

Zeigt direkt, warum Schadensfälle abgelehnt werden. Das ist wichtig, um die Richtlinien zur Risikoprüfung zu verbessern und unnötigen Aufwand für ungültige Schadensfälle zu vermeiden.

Dies ist üblicherweise ein benutzerdefiniertes Auswahllistenfeld am Objekt Claim/Case, das verpflichtend wird, wenn der Status auf 'Rejected' oder 'Closed - Denied' gesetzt wird.

Dieses Kennzeichen unterscheidet zwischen Aufgaben, die menschliche Sachbearbeiter erledigen, und solchen, die automatisierte Workflows, Regeln oder Systemintegrationen ausführen. So kann beispielsweise die erste Erfassung eines Schadenfalls vollständig automatisiert ablaufen.

Die Analyse der Automatisierung ist entscheidend, um die Prozesseffizienz zu verstehen. Sie hilft dabei, den Erfolg von Automatisierungsinitiativen zu messen, geeignete Schritte für eine künftige Automatisierung zu ermitteln und die Geschwindigkeit sowie Konsistenz automatisierter und manueller Aufgaben zu vergleichen.

Unterscheidet zwischen Aktivitäten von Menschen und Systemen. Das ist entscheidend, um die Auswirkungen und Wirksamkeit der Automatisierung zu bewerten.

Dieses Kennzeichen wird üblicherweise abgeleitet. Ist der einem Ereignis zugeordnete Benutzer ein allgemeiner Benutzer vom Typ 'System' oder 'Integration', wird das Kennzeichen auf true gesetzt.

Diese Kennzahl misst die gesamte Dauer eines Schadenfalls von der ersten Meldung bis zum endgültigen Abschluss. Sie ergibt sich aus der Differenz zwischen dem Timestamp des letzten und dem des ersten Ereignisses für eine bestimmte Claim ID.

Dies ist eine der wichtigsten Kennzahlen für die Prozessleistung. Sie wird direkt in der KPI 'Durchschnittliche Zykluszeit von Schadenfällen' und im Dashboard 'End-to-End-Zykluszeit von Schadenfällen' abgebildet. Prozessverbesserungsprojekte zielen häufig darauf ab, diesen Wert zu senken.

Misst die Gesamteffizienz des Prozesses von Anfang bis Ende und ist ein wichtiger Indikator für die Customer Experience.

Berechnetes Feld: Timestamp des letzten Ereignisses minus Timestamp des ersten Ereignisses für jede 'ClaimId'. Die Berechnung übernimmt das Process-Mining-Tool.

Die Kunden-ID verknüpft den Schadensfall mit der Person oder Organisation, die ihn eingereicht hat. In Salesforce ist dies üblicherweise ein Nachschlagefeld zum Objekt Account oder Contact.

Dieses Attribut ermöglicht eine kundenorientierte Sicht auf den Schadenbearbeitungsprozess. Es kann verwendet werden, um die Schadensfallhistorie pro Kunde zu analysieren, häufige Anspruchstellende zu erkennen und den Service individuell auszurichten. Außerdem ist es wichtig, um Schadensfalldaten mit weiteren Kundendaten aus einem CRM zu verknüpfen und so einen umfassenderen Überblick über das Unternehmen zu erhalten.

Ermöglicht eine kundenorientierte Analyse. So lassen sich Muster bei einzelnen Kunden nachvollziehen und die Auswirkungen des Schadenbearbeitungsprozesses auf die Kundenbeziehung messen.

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

Dieses Kennzeichen wird auf true gesetzt, wenn ein Schadenfall zu einer früheren Prozessphase zurückkehrt. Ein typisches Beispiel ist der Wechsel von 'Untersuchung abgeschlossen' zurück zu 'Zusätzliche Informationen angefordert'. Die Logik zur Erkennung von Nacharbeit basiert auf Prozesswissen.

Dieses Attribut ist eine wichtige Grundlage für das Dashboard 'Analyse von Nacharbeitsschleifen bei Schadenfällen' und die KPI 'Nacharbeitsquote'. Damit lassen sich Häufigkeit und Auswirkungen von Nacharbeit direkt quantifizieren. Nacharbeit ist eine wesentliche Ursache für Ineffizienz, höhere Kosten und längere Zykluszeiten.

Kennzeichnet ineffiziente Prozessschleifen direkt. So können Sie Nacharbeit einfach quantifizieren und ihre Ursachen gezielt analysieren.

Berechnetes Feld. Wird durch die Analyse der Aktivitätsabfolge für jeden Case abgeleitet. Folgt beispielsweise auf 'Aktivität A' die 'Aktivität B' und danach erneut 'Aktivität A', gilt das zweite Auftreten von 'A' als Nacharbeit.

Das Schadendatum gibt an, wann das von der Versicherungspolice abgedeckte Ereignis eingetreten ist. Es unterscheidet sich vom Datum der Einreichung des Schadensfalls.

Dieses 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 andere Bearbeitung erfordern. Das Datum liefert wertvollen Kontext für den gesamten zeitlichen Verlauf.

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

Dies wäre ein benutzerdefiniertes Datumsfeld am Objekt Claim, zum Beispiel 'DateOfLoss__c'.

Dieses Attribut gibt das Ergebnis in Kategorien an, üblicherweise mit Werten wie 'Eingehalten' oder 'Verfehlt'. Es wird ermittelt, indem das tatsächliche Abschlussdatum des Schadenfalls (der Timestamp der letzten Aktivität) mit dem Wert 'SlaTargetDate' verglichen wird.

Dies ist die zentrale Kennzahl für die KPI 'SLA-Einhaltungsquote' und das Dashboard 'Übersicht zur SLA-Konformität bei Schadenfällen'. Sie zeigt klar, ob die Zielvorgaben eingehalten wurden, und ist für Compliance-Berichte und das operative Management unverzichtbar.

Zeigt klar, ob die zeitlichen Zielvorgaben eingehalten werden. Das ist entscheidend für die Kundenzufriedenheit und die Einhaltung gesetzlicher Vorschriften.

Berechnetes Feld: Ist 'EndTime' des letzten Ereignisses kleiner oder gleich 'SlaTargetDate', lautet der Wert 'Eingehalten', andernfalls 'Verfehlt'. Diese Logik wird bei der Datentransformation oder im Process-Mining-Tool angewendet.

Das SLA-Zieldatum ist ein berechnetes oder manuell festgelegtes Datum, das die Frist für den Abschluss des Schadensfalls angibt. Es dient als Maßstab für die Termintreue.

Dieses Attribut ist wichtig, um die Leistung anhand der Zusagen gegenüber Kunden oder Aufsichtsbehörden zu überwachen. Es bildet die Grundlage für die KPI 'SLA-Einhaltungsquote' und das Dashboard 'Überblick zur SLA-Einhaltung bei Schadensfällen'. Damit kann das Unternehmen erfassen, welcher Anteil der Schadensfälle fristgerecht abgeschlossen wird, und erkennen, welche Schadensfallarten oder Abteilungen ihre Ziele verfehlen.

Legt das Leistungsziel für die Bearbeitungsdauer von Schadensfällen fest und ermöglicht die direkte Messung der SLA-Einhaltung.

Dies ist üblicherweise ein benutzerdefiniertes Formelfeld oder Datumsfeld am Objekt Claim/Case, das anhand des Einreichungsdatums und der Schadensfallart berechnet wird.

Dieses Attribut gibt den geografischen Kontext des Schadenfalls an, etwa den Bundesstaat, in dem der Schaden eingetreten ist, oder das Land des Versicherungsnehmers. Die Angaben lassen sich aus der Adresse des Versicherungsnehmers oder aus den Schadendetails ableiten.

Eine geografische Analyse kann regionale Trends bei Schadenarten, Häufigkeiten und Bearbeitungszeiten aufzeigen. Außerdem können Sie damit die Leistung verschiedener Regionalbüros vergleichen und die Einhaltung standortspezifischer Vorschriften prüfen.

Ermöglicht die geografische Analyse von Schadenfällen. So lassen sich regionale Leistungsunterschiede, Betrugsmuster oder die Auswirkungen lokaler Ereignisse erkennen.

Wird üblicherweise aus den Adressfeldern (z. B. 'BillingState', 'BillingCountry') des zugehörigen Account- oder Contact-Objekts abgeleitet.

Dieses Attribut erfasst den tatsächlich an die anspruchstellende Person gezahlten Betrag, wenn der Schadensfall abgeschlossen und reguliert wird. Aufgrund der Bewertung, Selbstbeteiligungen und Versicherungsgrenzen kann er 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 zum Ergebnis der Vergleichsverhandlungen. Als wichtige finanzielle Kennzahl zeigt er die Gesamtkosten der Schadensfälle.

Gibt die endgültigen finanziellen Auswirkungen eines Schadensfalls an und ist wichtig für Finanzanalysen, Rückstellungen und die Bewertung der Genauigkeit erster Schadenschätzungen.

Dies wäre ein benutzerdefiniertes Währungsfeld am Objekt Claim oder an einem zugehörigen Objekt Payment in Financial Services Cloud.

Die Versicherungsnummer verknüpft den Schadensfall mit der aktiven Versicherungspolice des Kunden. Sie liefert wichtige Informationen zu Versicherungsschutz, Deckungssummen und zur Historie des Versicherungsnehmers.

Auch wenn sie den Prozessablauf nicht immer direkt beeinflusst, ist sie ein wichtiges Kontextattribut. Damit lassen sich Schadensfalldaten mit Policendaten verknüpfen und genauer analysieren, ob bestimmte Policenarten mit häufigeren oder komplexeren Schadensfällen verbunden sind.

Verknüpft den Schadensfall mit der zugrunde liegenden Versicherungspolice. So lassen sich Muster zu bestimmten Policen oder Versicherungsarten umfassender analysieren.

Dies wäre ein Nachschlagefeld am Objekt Claim, das auf das Objekt 'InsurancePolicy' in Financial Services Cloud verweist.