Schadenfälle & Versicherungen

Der durchgängige Schadenprozess in der betrieblichen Praxis

Das Schadenmanagement verbindet Ereignisaufnahme, Beweissicherung, Risikobewertung, Versicherungskorrespondenz und kaufmännische Regulierung zu einem durchgängigen Prozess. Jeder Schadenfall ist ein eigener Vorgang mit Nummer, Status, Verantwortlichem, Frist und vollständigem Verlauf.

1. Omnichannel-Aufnahme & Primärverknüpfung

Ein Schadenfall entsteht aus einem konkreten Geschäftsvorfall – niemals aus dem Nichts:

• Meldewege: Interner Erfassungsdialog (/schaeden/neu), Telefon, E-Mail, Kundenportal, API oder ein Agent. Der Kanal wird am Fall gespeichert (internal, phone, email, portal, api, sales, service).
• Primärbezug: Über cap:claim.report wird der Fall mit seinem auslösenden Objekt verknüpft: Sendung, Retoure, Fertigungsauftrag, Arbeitsauftrag, Projekt, Artikel, Anlage, Fahrzeug, Charge, Bestellung, Kundenauftrag, Lagerbewegung, Einsatzbericht oder Mietbuchung. Der Primärbezug landet zusätzlich als Link mit Rolle primary in der Schadenakte.
• Nummernkreis: Die Schadennummer wird transaktionssicher aus dem Nummernkreis CLAIM vergeben; der Fall startet im Status Gemeldet (reported).

2. Beweissicherung & digitale Schadenakte

Vor jeder Reparatur oder Entsorgung werden Beweise gesichert:

• Fotos, Frachtbriefe mit Vorbehalt, Polizeiprotokolle, Gutachten, Rechnungen und Korrespondenz werden über cap:claim.attachment.add als Dokumente des Dokumentmoduls an die Akte gebunden (Arten: photo, report, invoice, correspondence, evidence, other).
• Jede fachliche Handlung – Statuswechsel, Notiz, KI-Triage, Reserve, Regress – erzeugt einen Eintrag in claim_events (cap:claim.event.add). Dieses Journal ist append-only: Die Anwendungsrolle besitzt kein UPDATE/DELETE.
• Fehlen Belege, fordert cap:claim.photo.request per Aufgabe gezielt Schadenfotos nach.

3. Kaskadierende Klassifikation & Friststeuerung

Die Schadenklassifikation ist dreistufig und datengetrieben (Bereich → Kategorie → Ursache):

• Neun Bereiche: Transport & Versand, Produktion & Fertigung, Lager & Logistik, Kundenretoure & Reklamation, Fuhrpark & Fahrzeuge, Gebäude & Anlagen, Service & Montage, Lieferant & Beschaffung, Sonstiges.
• Jede Kategorie kennt nur ihre zulässigen Ursachen; Taxonomie-Verstöße werden serverseitig abgewiesen (validate_taxonomy). Dadurch sprechen Formular, API, KI-Triage und Auswertung dieselbe Sprache.
• Die Schwere (low, normal, high, critical) setzt die Bearbeitungsfrist (due_at): 14, 7, 3 bzw. 1 Tag ab Schadendatum. Die Priorität (low bis urgent) steuert die Bearbeitungsreihenfolge.

4. KI-Triage & Doppelmeldungs-Radar

• cap:claim.triage klassifiziert den Fall anhand der Fakten: Bereich, Kategorie, Ursache, Schwere, Priorität, Zusammenfassung, fehlende Informationen und empfohlene nächste Schritte. Die KI darf keine Beträge, Daten oder Personen erfinden; Schadenbeschreibungen und Dokumenttexte gelten als nicht vertrauenswürdiger Inhalt (Prompt-Injection-Schutz).
• Mit apply=true übernimmt der Fall die Vorschläge und erhält eine neue Frist; ohne Freigabe bleibt es bei einem Vorschlag.
• cap:claim.ai.duplicates sucht ähnliche Fälle (gleiche Retoure, Artikel, Kunde oder Objekt innerhalb von 90 Tagen) und schützt vor Doppelregulierung.

5. Untersuchung, Ursachenanalyse & 8D/CAPA

• Nach der Triage wird der Fall über cap:claim.mark_triaged und cap:claim.investigate in Untersuchung geführt.
• cap:claim.capa.update pflegt die 8D-/CAPA-Struktur: Ursache (root_cause), Sofortmaßnahme (containment_action), Korrekturmaßnahme (corrective_action), Vorbeugemaßnahme (preventive_action) und Wirksamkeitsprüfung (verification). Das Kennzeichen is_8d markiert Fälle mit formaler 8D-Pflicht.
• Über cap:claim.link lassen sich zusätzliche Beziehungen – etwa betroffene Charge, Lieferant, Maschine oder Rücklieferung – mit Rolle affected, source, recovery oder context dokumentieren.

6. Deckungsprüfung & Rückstellung

• Aktive Policen werden über insurance_policies geführt. find_matching_policies gleicht Deckungsart, Fahrzeug und Anlage ab; cap:policy.register und cap:policy.update pflegen Laufzeit, Prämie, Selbstbehalt und Erinnerungsvorlauf.
• cap:claim.reserve.set setzt die Schadenrückstellung und dokumentiert sie im Verlauf; cap:claim.ai.reserve schlägt auf Basis von Schätzung, gebuchten Kosten und historischer Regulierungsquote einen Wert vor.
• cap:claim.settlement.propose hält einen Vergleichsvorschlag fest, ohne ihn zu buchen.

7. Einreichung beim Versicherer & Prüfung

• cap:claim.ai.letter entwirft ein formelles deutsches Schadenmelde-Schreiben mit Police, Hergang, Höhe, Selbstbeteiligung und Bitte um Deckungsbestätigung – ausschließlich aus gelieferten Fakten.
• cap:claim.submit reicht den Fall ein (Status Eingereicht (submitted)). Die Einreichung ist freigabepflichtig, weil sie eine externe Wirkung gegenüber dem Versicherer entfaltet.
• Geht die Rückmeldung ein, führt cap:claim.review den Fall in Prüfung (in_review). Aus der Prüfung kann der Fall wieder nach Gemeldet zurückfallen (cap:claim.reopen), wenn neue Erkenntnisse oder Nachmeldungen vorliegen.

8. Anerkennung, Regulierung & Regress

• cap:claim.approve erfasst Deckungszusage und Anerkennungsbetrag (approved_amount), cap:claim.reject lehnt begründet ab.
• cap:claim.settle bzw. cap:claim.settlement.pay regulieren den Fall und setzen den Auszahlungsbetrag (settled_at, settled_amount). Die Zahlung ist als externe Wirkung besonders geschützt und benötigt eine menschliche Bestätigung.
• cap:claim.subrogation.open eröffnet den Regress gegen Dritte (Frachtführer, Lieferant, Schädiger); der erwartete Rückfluss wird als recovery_amount geführt.
• cap:claim.close schließt die Akte nach Regulierung oder Ablehnung revisionssicher ab.

9. Schadenkosten & kaufmännische Bewertung

• cap:claim.cost.book erfasst Kostenpositionen (Reparatur, Ersatz, Fracht, Gutachter, Rechtsberatung, Sonstiges) mit Menge, Einzelpreis, Lieferant, Beleg und Status; cap:claim.cost.remove storniert eine Position, ohne den Verlauf zu löschen.
• Die Summe der Kostenpositionen fließt in die semantische Auswertung (claim.cost_total) und in die Reservenempfehlung ein.
• Schätzung, Reserve, Anerkennung, Regulierung und Regress bleiben getrennt ausgewiesen – so entsteht eine belastbare Soll-Ist-Betrachtung je Fall und Bereich.

10. Abschluss, Policenpflege & Lernschleife

• Auslaufende Policen werden über expiring_policies erkannt; cap:policy.renew verlängert die Laufzeit und aktiviert die Police wieder. Der Erinnerungsvorlauf (reminder_days) steuert die Fristenwarnung.
• Abgeschlossene Fälle dienen der Ursachenanalyse: Bereichs-, Kategorie- und Ursachenstatistiken zeigen wiederkehrende Fehlerquellen; CAPA-Maßnahmen und Verknüpfungen zu Fertigungs-, Lager- und Lieferantenprozessen schließen die Lernschleife.
• Der Statuswechsel erzeugt das Outbox-Signal CLAIM_STATUS_CHANGED; nachgelagerte Prozesse (Aufgaben, Benachrichtigungen, Auswertungen, Workflows) können darauf reagieren.

KI-Consultant Blueprint: Customizing & No-Code Architektur

Dieser Leitfaden dient Solution Architects und autonomen KI-Consultants als Handlungsvorlage für kundenspezifische Schadenprozesse auf der No-Code-Engine.

1. Analyse der Kundenanforderung (Soll-Ist-Abgleich)

Der Berater prüft zuerst:

• Welche Schadenarten und Bereiche sind branchenspezifisch relevant (z. B. Lebensmittel: Kontamination/Verfall; Maschinenbau: Maschinenschaden/Stillstand; Spedition: Transportschaden/Regress)?
• Welche Meldewege müssen angebunden sein (Portal, E-Mail-Postfach, API, Außendienst-App)?
• Welche Freigabeschwellen gelten (z. B. Regulierung ab 5.000 EUR durch die Geschäftsleitung)?
• Welche Fristen und Eskalationen sind vertraglich oder versicherungsseitig vorgegeben?

2. No-Code Zusatzfelder (Custom Fields)

Im Customizing Studio (/semantic/customizing) lassen sich Felder auf claim und insurance_policy anlegen:

• Auf Claim:
  • recall_relevant (Ja/Nein): Löst bei Wahrheit eine produktbezogene Eskalation aus.
  • supplier_claim_number (Text): Referenz auf die Korrespondenz mit dem Lieferanten.
  • incident_shift (Auswahl: Früh/Spät/Nacht): Auswertung von Schichtclustern.
  • safety_relevant (Ja/Nein): Kopplung an Arbeitssicherheitsvorfälle.
• Auf InsurancePolicy:
  • broker_contact (Text): Ansprechpartner des Maklers.
  • coverage_limit (Dezimal): Deckungssumme für Plausibilitätsprüfungen.
  • notice_period_days (Ganzzahl): Kündigungsfrist für automatische Erinnerungen.

3. No-Code Workflow Canvas DAGs

Blueprint A: Eskalation kritischer Schäden

• Trigger: cap:claim.report mit severity = critical oder safety_relevant = true.
• Condition: estimated_amount > threshold OR claim_type = liability.
• Human-in-the-Loop: Erzeugt eine Aufgabe für Schadenleitung und Geschäftsführung; Optionen Freigeben (cap:claim.approve) oder Ablehnen (cap:claim.reject).
• Parallelzweig: Benachrichtigt die Versicherung über cap:claim.ai.letter als Entwurf – der Versand bleibt manuell.

Blueprint B: Beweislücken-Workflow

• Trigger: Statuswechsel nach triaged ohne Anhang der Art photo oder report.
• Action: cap:claim.photo.request erzeugt eine Aufgabe mit Frist; der Fall bleibt in Untersuchung.
• Exit: Sobald ein Foto/Beleg angehängt ist (claim.attachment.add), schließt der Workflow die Aufgabe.

Blueprint C: Policy-Ablauf & Verlängerung

• Trigger: Zeitplan oder expiring_policies-Ereignis (< reminder_days).
• Action: Aufgabe für Versicherungsverantwortliche; nach Entscheidung cap:policy.renew oder cap:policy.update.
• Guard: Keine automatische Verlängerung ohne dokumentierte Freigabe.

4. Validierungsregeln & Formular-Customizing

• Betragskonsistenz: settled_amount <= approved_amount <= estimated_amount * 1.25 als Hinweisregel (keine harte Sperre, da Nachträge möglich sind).
• Pflichtfelder je Schwere: Ab high müssen Bereich, Kategorie, Ursache und mindestens ein Beweismittel vorliegen.
• Fristen: due_at wird bei Änderung der Schwere neu berechnet; Überfälligkeit wird als claim.overdue im semantischen Kontext sichtbar.
• Datenschutz: Freitextfelder (Titel, Beschreibung, Notizen) niemals in generische Agenten- oder Analysekontexte aufnehmen – nur strukturierte Fakten verwenden.