Prognose von Garantieansprüchen & Frühwarnung vor Feldausfällen

Hersteller von Fahrzeugen, Maschinen und Konsumgütern zahlen für Ausfälle, die erst Monate nach der Auslieferung auftreten. Das klassische Garantieberichtswesen zählt Ansprüche im Nachhinein; bis dahin können Tausende fehlerhafter Einheiten im Feld sein. Dieser Anwendungsfall verknüpft Ansprüche, Nutzungs- und Felddiagnosedaten mit Bau- und Lieferantenchargendaten, prognostiziert Schadensquoten mit Überlebenszeit-/Zuverlässigkeitsmodellen und meldet entstehende Ausfallcluster frühzeitig, damit Qualität, Finanzwesen und Service bei Rückstellungen, Servicekampagnen, Lieferantenregress und Rückrufen handeln können.

Problem & Nutzen

• Heute: Garantiedaten liegen in Händler-/Servicesystemen, Baudaten in MES/ERP, Felddaten in Telematikplattformen und Beschwerden im Freitext. Qualitätsteams finden Probleme anhand monatlicher Diagramme der Ansprüche je tausend Fahrzeuge. Diese hinken dem tatsächlichen Beginn der Ausfälle hinterher und verdecken Nutzungseffekte (Laufleistung, Betriebsstunden, Klima). Das Finanzwesen legt Garantierückstellungen anhand historischer Quoten fest.
• KI-Nutzen: (1) frühere Erkennung einer fehlerhaften Charge, Lieferantencharge oder Softwareversion; (2) bessere Prognosen von Schadensquote und Kosten, einschließlich zensierter (noch nicht ausgefallener) Einheiten; (3) gezielte Ansprache gefährdeter Seriennummern statt pauschaler Kampagnen; (4) Einordnung von Freitextbeschwerden in Fehlerarten; (5) Belege für den Lieferantenregress.
• Belegte Nutzenangaben (vom Anbieter berichtet, nicht unabhängig): Eine Fallstudie von Bosch Software Technologies für einen britischen Premium-Automobilhersteller berichtet, die Garantiekosten seien um 7 % pro Jahr gesunken und Feldausfälle seien mindestens 2 Monate im Voraus vorhergesagt worden, und zwar mit Diagnosedaten in Kombination mit Anspruchs- und Hotline-Daten [1]. Bosch nennt für sein Angebot geschätzte Einsparungen von 7–10 % der jährlichen Garantieausgaben [2]. Betrachten Sie dies als Marketingaussagen; messen Sie Ihre eigene Ausgangslage.
• Regulatorischer Druck: Hersteller müssen Sicherheitsmängel melden und Rückrufe durchführen; in Deutschland erwartet das KBA, dass Hersteller es informieren, sobald Hinweise auf Mängel vorliegen [3]. Die EU- Produktsicherheitsverordnung 2023/988 und die neue Produkthaftungsrichtlinie (EU) 2024/2853 (Software gilt als Produkt) erhöhen die Kosten einer späten Erkennung [4][5].

Varianten

• Automobilhersteller (OEM) / Tier-1: Analyse auf Ebene der Fahrgestellnummer mit Diagnose-Fehlercodes und Telematik; zu EV-spezifischen Komponenten (Batterie, Leistungselektronik) siehe PRED-026.
• Maschinen- und Anlagenbauer (Mittelstand): Analyse auf Seriennummernebene, Betriebsstunden als Nutzungsachse, Berichte der Servicetechniker; oft nur Ansprüche plus ERP-Baudaten.
• Unterhaltungselektronik & Haushaltsgeräte: Retouren- und RMA-Daten, App-/IoT-Telemetrie, Bewertungs- und Social-Media-Texte als zusätzliches Frühsignal.
• Prognose der Garantierückstellungen (Sicht des Finanzwesens): Abwicklungsdreiecke der Anspruchskosten nach Baumonat und Alter als Grundlage für Abgrenzungen und IFRS-Rückstellungen.
• Händler-/Anspruchsbetrug und Fehldiagnosen (zusammengeführter Umfang): auffällige Anspruchsmuster von Händlern, Wiederholungsreparaturen und Quoten „kein Fehler gefunden“ erkennen; als Variante dokumentieren, nicht als eigenes System [2].
• Anbieter von Garantieverlängerungen/Versicherer: Preisgestaltung und Schadenquoten, siehe PRED-037.

So funktioniert es

1. claims + service + telematics + build/supplier data + complaint text
2. data mart keyed by VIN/serial (+ part, lot, plant, software version)
3. feature engineering (age, mileage/hours, exposure; censoring flags)
4. failure-mode classification of free text (embeddings / small classifier / LLM)
5. models: Weibull/survival reliability, claim-rate forecast, change-point & cluster detection
6. early-warning alert: segment, exposed population, estimated claim-cost trajectory
7. quality engineer review
8. containment / service campaign / supplier claim / recall board
9. finance: reserve update; feedback of confirmed root causes as labels

• Zuerst Zuverlässigkeitsstatistik: Weibull- und Competing-Risk-Modelle auf Ansprüchen mit zensierten (nicht ausgefallenen) Einheiten sind das Rückgrat; eine Analyse im Laufleistungsbereich kann nutzungsabhängige Ausfall- mechanismen aufdecken, die einfache Raten pro Alter verbergen [6].
• ML obendrauf: Gradient-Boosting-Modelle für Überlebenszeit oder Klassifikation sagen das Ausfallrisiko je Einheit aus Bau-, Lieferanten- und Feldsignalen voraus; Graph-Clustering verknüpft Fahrzeuge, die Chargen oder Bedingungen teilen [1].
• Text: Techniker-Notizen („Verbatims“) werden mit Embeddings plus einem Klassifikator auf Fehlerarten abgebildet, oder mit einem LLM mit kontrollierter Codeliste; die LLM-Ausgabe ist nie die endgültige Ursache.
• Mensch-in-der-Schleife (Human-in-the-Loop): Jede Meldung geht an einen Qualitäts-/Zuverlässigkeitsingenieur; Rückruf- und Kampagnen- entscheidungen bleiben bei einem Sicherheits-/Rückrufgremium und der Rechtsabteilung.

Datenaufbereitung

Benötigt werden Garantieanspruchsdaten, Bestands- und Verkaufsdaten, Bau- und Lieferantenchargendaten sowie, soweit verfügbar, Telematik- und Diagnosecodes. Im Mittelstand liegen diese im ERP, in einem Service- oder CRM-Werkzeug, in Qualitäts-Excel-Tabellen und teils in Papier-Reparaturberichten; Freitexte von Technikern stehen in Mail- und Ticketsystemen. Typische Lücken sind fehlende Verknüpfungen zwischen Anspruch und Serien- oder Chargennummer, uneinheitliche Fehlercodes, doppelte Ansprüche, reine Freitextbeschreibungen, unbekannte Inbetriebnahmedaten und Lieferantendaten, die beim Lieferanten verbleiben.

Aufbereitungsschritte: eine Tabelle je Seriennummer aufbauen, die Bau-, Chargen-, Verkaufs- und Anspruchsdaten verknüpft (PREP-005, PREP-011); Fehlercodes vereinheitlichen und ein Kategorienschema festlegen (PREP-019); Labels aus abgeschlossenen Ansprüchen gewinnen (PREP-020); Kundendaten pseudonymisieren (PREP-022). Typische Werkzeuge sind SQL/dbt, Python mit pandas und OCR für Papierberichte (PREP-006). Prüfen Sie zuerst die Reife (PREP-001, GUIDE-003). Rechnen Sie damit, dass etwa 50–60 Prozent des Projektaufwands in die Datenaufbereitung gehen, da die Modellqualität von der Rückverfolgbarkeit von Chargen und Seriennummern abhängt.

Umsetzungswege

Welcher Weg für wen

• smb: B, weil Anspruchs-, Bau- und Lieferantendaten im eigenen ERP-/Servicesystem liegen und für einen kleinen Bestand kein Standardprodukt passt.
• enterprise: B, weil Cloud-ML-Dienste auf der vorhandenen Datenplattform schnell skalieren; Selbstbetrieb lohnt sich nur bei sehr großen Anspruchsvolumen.
• developer: B, weil verwaltete Zeitreihen- und Tabellen-ML-Dienste den Weg zu einem ersten Frühwarnmodell verkürzen.

Weg A — Kaufen (Standardsoftware)

• Anbieter für Garantie- und Feldqualitätsanalytik: Bosch Software Technologies Warranty & Diagnostics mit Frühwarnsystem (deutsch) [2]; Tavant Warranty Analytics (Frühwarnung, Ausfall-Clustering, Weibull/Überlebenszeit, Rückrufanalyse) [7]; Engineering-Dienstleister wie IAV (deutsch) und AVL (Österreich) bieten Feldüberwachung und Ausfallprognose an.
• Garantieabwicklung in ERP-/Service-Suiten: SAP- und Salesforce-basierte Serviceplattformen decken die Anspruchsbearbeitung ab; Analytik ist in der Regel ein Zusatzmodul.
• Zuverlässigkeitssoftware: HBKs ReliaSoft-Weibull-Werkzeuge für die klassische Lebensdaueranalyse.
• A wählen, wenn: Datenvolumen wie in der Automobilbranche vorliegen, kein eigenes Data-Science-Team besteht und ein Anbieter bereits an Ihre Händler-/DMS-Systeme anbindet.

Weg B — Auf Cloud-KI-Diensten aufbauen (für die meisten empfohlen)

• Datenplattform in einer EU-Region: Azure/AWS/Google/STACKIT oder Databricks/Snowflake; Ansprüche und Baudaten über die Seriennummer verknüpft.
• Prognose: verwaltetes AutoML oder Zeitreihendienste; Foundation-Modelle wie Chronos-2 (Apache-2.0) unterstützen Kovariaten für Schadensquoten-Zeitreihen [8].
• Text und Triage: LLM-API in einer EU-Region (Claude, Gemini, GPT, Mistral) zur Einordnung der Verbatims in Fehlerarten und zur Zusammenfassung der Clusterbelege für Ingenieure; Embeddings für die Suche nach ähnlichen Fällen.
• Orchestrierung/BI: geplante Pipelines, Weiterleitung von Meldungen an das Qualitätswerkzeug (CAQ/8D) und ein Dashboard für Qualität und Finanzwesen.

Weg C — Selbst betreiben (Open Source)

• Statistik/ML: lifelines (Überlebenszeitanalyse), reliability (Weibull-Anpassung, zensierte Daten, Kaplan-Meier; LGPLv3), scikit-survival, Gradient Boosting (LightGBM/XGBoost), ruptures-/Prophet-artige Werkzeuge zur Erkennung von Strukturbrüchen [9][10][11].
• Text: offenes Embedding-Modell plus ein kleiner feingetunter Encoder-Klassifikator; optional ein lokales LLM zur Zusammenfassung.
• Prognose: Chronos-2-Gewichte lokal betreiben [8].
• Hardware: HW1 (CPU-Server) genügt für Tabellen-/Überlebenszeitmodelle auf Millionen von Ansprüchen; HW2 nur, wenn ein lokales LLM oder Embedding-Stapelaufträge hinzukommen. Der Aufwand liegt überwiegend im Data Engineering.

Weg D — Eigenes Training

Lohnt sich bei einer langen Anspruchshistorie (mehrere Produktgenerationen) und reichhaltigen Felddaten: Ausfallrisikomodelle je Komponente trainieren, Zuordnungen von Bauparametern zu Feldausfällen lernen oder einen Klassifikator auf Ihrer eigenen Fehlercode-Taxonomie und mehrsprachigen Techniker-Notizen feintunen. Dafür sind Ergebnisse mit bestätigter Ursache nötig (bestätigte Mängel, Kampagnen), die selten sind; rechnen Sie daher mit wenigen positiven Beispielen und nutzen Sie bayessche/hierarchische Modelle sowie strenge Rückwärtstests an vergangenen Vorfällen.

Stand der Technik (2026)

• Überlebenszeit zuerst, ML ergänzend: Best Practice bleibt Zuverlässigkeitsstatistik mit sauberem Umgang mit Zensierung und Nutzung, ergänzt durch ML für das Risiko je Einheit und durch Clustering für die Früherkennung [1][6].
• Verknüpfung von Bau und Feld (Lieferantenchargen, Prozessparameter, Softwarestände) ermöglicht es, dass die Erkennung dem Anspruchsvolumen vorausgeht; Anbieter versprechen Vorlaufzeiten von Monaten, doch unabhängige Benchmarks sind rar. Die einzige gemessene Vorlaufzeit, die wir in einem Primärdokument eines Anbieters fanden, ist „mindestens 2 Monate“ [1].
• Felddiagnose- und OTA-Daten (vernetzte Fahrzeuge, IoT-Maschinen) verlagern die Erkennung von Ansprüchen auf Symptome, bevor eine Reparatur abgerechnet wird.
• LLMs strukturieren unstrukturierte Verbatims und entwerfen Clusterzusammenfassungen; Zeitreihen-Foundation- Modelle sind eine Option für Schadensquotenprognosen mit Kovariaten [8].
• Grenzen: Meldeverzögerungen (Ansprüche treffen Monate nach dem Ausfall ein), wechselnde Anspruchsrichtlinien und Kulanzpraktiken, Kodierqualität der Händler, kleine Stichproben bei neuen Produkten, Störfaktoren (Laufleistung, Klima, Fahrverhalten) und Fehlalarme, die das Vertrauen untergraben. Eine Korrelation zwischen einer Charge und Ausfällen ist keine Ursache; eine technische Bestätigung ist erforderlich. Es gibt keinen öffentlichen Benchmark, validieren Sie daher durch Rückwärtstests an vergangenen, bekannten Vorfällen.

Gemeinsame Bausteine & Kombinationen

• Gleicher statistischer Stack (tabular-ml + time-series + anomaly-detection): PRED-006 (sensorbasierte vorausschauende Wartung eigener Maschinen; ihre Flotten- und RUL-Modelle lassen sich auf Kundenflotten übertragen), PRED-026 (Batterie-SoH/RUL als Eingang für EV-Garantie), PRED-024 (Prozessüberwachung auf Ereignisprotokollen, z. B. Verzögerungen bei der Anspruchsbearbeitung), PRED-001 (Ersatzteil- und Bedarfsprognose aus prognostizierten Ansprüchen).
• Vorgelagerte Daten: ANOM-005 (Prozessanomalien am Bandende/in der Produktion als Signale für die Chargenqualität), DOC-019 (Lieferantenzertifikate), DOC-014 (Auswertung von Serviceberichten und 8D-Dokumenten), ANOM-011 (Lieferantenrisiko).
• Nachgelagert: KNOW-004 / KNOW-021 (Servicehandbuch- und Ersatzteilsuche als Beitrag zu Lösungen), PRED-037 (Schadenschwere und Reservierung in der Versicherung, gemeinsame versicherungsmathematische Methoden).
• Bausteine: ein nach Fahrgestell-/Seriennummer geschlüsselter Data Mart, MES/ERP- und DMS-Konnektoren, ein Ereignis- strom für Telematik, ein Embedding-Index der Verbatims. Hardware: HW1-CPU-Server für alle statistischen Teile.

Aufwand, Kosten & Kennzahlen

• Weg A: 2–4 Monate für Einführung und Datenintegration; Abonnement oder Preis pro Fahrzeug/Einheit.
• Weg B: 4–9 Monate bis zu einer Produktivpipeline; Data Engineering und Datenbereinigung dominieren die Kosten gegenüber Modell-/API-Nutzung.
• Weg C: 6–12 Monate; ein CPU-Server und ein kleines Daten-/Qualitätsteam.
• Weg D: kommt mit 3–6 Monaten hinzu, sobald die Basispipeline steht.
• Kennzahlen: Vorlaufzeit der Erkennung gegenüber konventionellem Reporting (rückwärts getestet), Trefferquote (Precision) der Meldungen, Garantiekosten je Einheit, Prognosefehler der Anspruchskosten (z. B. MAPE je Baukohorte), Größe der betroffenen Population bei Erkennung, Lieferantenregresse, Zeit von der Meldung bis zur Eindämmung.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung und die Abteilungsleitung Qualität/Finanzen von Anfang an ein, da Rückstellungen und Rückrufentscheidungen betroffen sind. Die Datenverantwortlichen (ERP, Service) und die IT bauen die Datenverknüpfung auf; Lieferanten müssen der Weitergabe von Chargen- und Prozessdaten zustimmen, üblicherweise über Vertragsklauseln, die die Rechtsabteilung prüft. Der Betriebsrat wird normalerweise nicht ausgelöst, da das System Produkte und nicht das Verhalten von Beschäftigten analysiert; informieren Sie ihn dennoch nach §90 Abs. 1 Nr. 3 BetrVG, wenn sich Arbeitsabläufe von Technikern oder im Service ändern, und prüfen Sie, dass Techniker-Kennungen nicht ausgewertet werden. Sind Kunden- oder Fahrgestellnummerndaten personenbezogen, beziehen Sie die/den Datenschutzbeauftragte(n) früh ein, pseudonymisieren Sie und führen Sie eine Datenschutz-Folgenabschätzung (DSFA) nur durch, wenn Profiling in großem Umfang stattfindet; schließen Sie mit jedem Cloud-Auftragsverarbeiter einen Auftragsverarbeitungsvertrag (AVV) ab.

Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) mit einer kurzen Schulung für Qualitätsingenieure zu Unsicherheitsbändern und Fehlalarmen. Starten Sie mit einer Produktlinie als Pilotgruppe (GUIDE-009). Typische Sorge: Meldungen ersetzen das Expertenurteil; begegnen Sie dem, indem Ingenieure bei jedem Rückruf oder Lieferantenregress die Entscheidenden bleiben und das Modell nur priorisiert. Siehe GUIDE-008 und GUIDE-005.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; dies ist Produktqualitätsanalytik, kein Anwendungsfall nach Anhang III. Sensibler wird es, wenn das Modell eine Sicherheitskomponente eines regulierten Produkts ist oder Entscheidungen über Personen steuert (z. B. Ablehnung eines Kundenanspruchs) — dann sind Art. 6 und Anhang III zu prüfen. Die KI-Kompetenz (Art. 4) gilt [12].
• Anspruchsentscheidungen gegenüber Kunden: die automatisierte Ablehnung einzelner Garantieansprüche auf Basis von Profiling erfordert menschliche Prüfung und Fairnessprüfungen (DSGVO Art. 22, soweit anwendbar).
• DSGVO: Fahrgestellnummer, Telematik und Reparaturhistorie sind personenbezogene Daten, wenn sie einem Halter zuordenbar sind; beschränken Sie sich auf pseudonymisierte Kennungen, legen Sie Zweck und Aufbewahrung fest, nutzen Sie berechtigtes Interesse oder Vertrags- grundlage und beachten Sie den EU Data Act sowie die Fahrzeugdatenregeln zum Zugang.
• Produktsicherheit: Analytik, die einen Sicherheitsmangel sichtbar macht, begründet eine Handlungspflicht (Meldung an das KBA in Deutschland [3]; GPSR 2023/988 [4]; Richtlinie (EU) 2024/2853 über die Produkthaftung, von den Mitgliedstaaten bis Dezember 2026 umzusetzen [5]). Dokumentieren Sie den Erkennungsprozess und die Entscheidungen; unterdrücken Sie keine Meldungen.
• Risiken und Gegenmaßnahmen: Fehlalarme (Schwellenwerte für Meldungen festlegen, Prüfgremium), Manipulation von Codes durch Händler (Audits), Datensilos (Datenverantwortungsvereinbarung mit Lieferanten), übermäßiges Vertrauen in LLM- Ursachenaussagen (Freigabe durch Ingenieure).

Erste Schritte

1. Die Basistabelle aufbauen: eine Zeile je Einheit mit Baudatum, Werk, Charge, Inbetriebnahmedatum, Nutzung und Anspruchshistorie sowie einem Zensierungskennzeichen. Zuerst die Serien-/Fahrgestellnummern-Schlüssel bereinigen.
2. Den aktuellen Bericht der Ansprüche je tausend Einheiten nachbilden und je wichtiger Komponente ein Weibull-Modell anpassen (lifelines oder reliability), um eine Basisprognose und einen Rückstellungsvergleich zu erhalten.
3. Rückwärtstest: 3–5 bekannte vergangene Qualitätsvorfälle nehmen und messen, wie früh die Clustererkennung sie gemeldet hätte.
4. Bau-/Lieferantenchargen- und Felddiagnosemerkmale sowie einen Fehlerart-Klassifikator für Freitext ergänzen.
5. Meldungen in den 8D-/CAQ-Prozess einbinden, mit wöchentlicher Prüfung durch Qualität, Service und Finanzwesen.

Quellen

1. Bosch Software Technologies — AI driven Warranty Management Solution (case study, UK premium OEM) — https://www.bosch-softwaretechnologies.com/media/documents/downloads/ai_and_bigdata/Warranty_Cost_management_2.pdf
2. Bosch Software Technologies — Warranty and diagnostics (early warning system, estimated 7–10% savings) — https://www.bosch-softwaretechnologies.com/en/services/enterprise-services/ai-and-big-data/warranty_and_diagnostics/
3. Kraftfahrt-Bundesamt — Rückrufe (recalls, manufacturer reporting duties) — https://www.kba.de/DE/Themen/Marktueberwachung/Rueckrufe/rueckrufe_node.html
4. Regulation (EU) 2023/988 General Product Safety Regulation — https://eur-lex.europa.eu/eli/reg/2023/988/oj
5. Directive (EU) 2024/2853 on liability for defective products — https://eur-lex.europa.eu/eli/dir/2024/2853/oj
6. HBK — Analysis of automotive warranty data in the mileage domain (HBK/ReliaSoft article; original link no longer available)
7. Tavant — warranty analytics product material (early warning, failure clustering, Weibull/survival) — https://www.tavant.com/
8. Amazon Science — Chronos forecasting models (Chronos-2, Apache-2.0) — https://github.com/amazon-science/chronos-forecasting
9. lifelines — survival analysis in Python — https://lifelines.readthedocs.io/en/latest/
10. reliability — Python library for reliability engineering (LGPLv3) — https://reliability.readthedocs.io/en/latest/
11. scikit-survival — https://scikit-survival.readthedocs.io/en/stable/
12. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj