KPIs und Grenzwerte

Reference · Seed-Stand: 2026-09-24 (MR !26 „KPI Threshold Anpassung", CU-123wka4jp4w)

Grenzwerte liegen zur Laufzeit in der Tabelle evaluation_rules und sind dort änderbar. Die folgenden Tabellen dokumentieren die Seed-Standardwerte (database/seeders/EvaluationRulesSeeder). Die je Umgebung wirksamen Werte zeigt php artisan kpi:rule:list — bei Abweichung gilt die Datenbank.

Händler-KPIs (scope='supplier')

Bewertet gegen die gespeicherten, vom Portal gelieferten Werte des Händlers. Alle mit Operator >= — ein höherer Wert ist schlechter.

kpi_key	KPI	Kritisch ab	Riskant ab	Einheit
cost_rate	Kostenquote (Verschleißkosten / UVP)	7,5	10,0	%
submission_rate_service_dealer	Einreichungsquote Servicehändler	160,0	180,0	%
submission_rate_delivering_dealer	Einreichungsquote ausliefernder Händler	160,0	180,0	%
correction_rate	Korrektur-Quote	3,0	5,0	%

Servicefall-KPIs (scope='service')

Bewertet gegen die im evaluation-request mitgelieferten Werte des Einzelfalls.

kpi_key	KPI	Kritisch ab	Riskant ab	Operator	Einheit
wear_cost	Verschleißkosten des Servicefalls	150,0	250,0	>=	€
service_cost_rate	Kostenquote des Falls (Verschleißkosten / UVP)	—	10,0	>=	%
ordinary_wear_violated	Gewöhnlicher Verschleiß	—	1,0	<	Flag

Semantik ordinary_wear_violated: Das Portal sendet 1 = gewöhnlicher Verschleiß eingehalten, 0 = nicht eingehalten (siehe ServiceCaseKpiKey::OrdinaryWearViolated im Monolith). Mit Operator < und Grenze 1.0 heißt das: Riskant, sobald der Verschleiß nicht eingehalten ist. Der Key-Name (violated) ist historisch und beschreibt das Gegenteil des gesendeten Werts — beim Lesen von Payloads nicht verwirren lassen.

Wertkonventionen

• Prozentwerte als Zahl: 5 % wird als 5.0 publiziert und verglichen, nicht als 0.05. Einreichungsquoten können über 100 liegen (z. B. 300.0).
• wear_cost in Euro.
• Grenzen sind inklusiv (Operator >=): Ein Wert exakt auf der Grenze fällt in das jeweilige Band.
• ordinary_wear_violated ist ein Flag: 1 = eingehalten, 0 = nicht eingehalten (trotz des Namens — siehe Kasten oben).
• Fehlende Grenze = Band existiert nicht: service_cost_rate und ordinary_wear_violated kennen keine Kritisch-Stufe.

Banding

Je Wert wird zuerst die Riskant-Grenze geprüft, dann die Kritisch-Grenze (KpiBander). Spaltenzuordnung in evaluation_rules:

Spalte	Enthält
critical_threshold	Riskant-Grenze (schwerste Stufe)
risky_threshold	Kritisch-Grenze (Warnstufe)

Die englischen Spaltennamen sind nach Schweregrad benannt und laufen den deutschen Fachbegriffen entgegen — siehe Ampel-Logik.

Cluster-Regeln (ClusterDeriver)

Pro Bereich (Händler bzw. Servicefall) über alle gebandeten KPIs:

• ≥ 1 KPI Riskant oder ≥ 2 KPIs Kritisch → Cluster Riskant
• sonst ≥ 1 KPI Kritisch → Cluster Kritisch
• sonst → Cluster Unauffällig

Prüfungsintensitäts-Matrix (AuditIntensityMatrix)

Zeilen = Servicefall-Cluster, Spalten = Händler-Cluster, Wert = Prozent:

	Händler Unauffällig	Händler Kritisch	Händler Riskant
Servicefall Unauffällig	0	25	100
Servicefall Kritisch	50	50	100
Servicefall Riskant	100	100	100

Regel-Auflösung

• case_type = '*' gilt für jeden Request; existiert zusätzlich eine Regel mit dem konkreten case_type für denselben kpi_key, gewinnt die konkrete (RuleMatcher). Aktuell gibt es nur den Case-Type technical_service.
• Jede anwendbare Regel ist Pflicht: Fehlt ihr KPI-Wert, ist das Ergebnis incomplete (keine Teilbewertung).

Historie der Grenzwert-Änderungen

Datum	Änderung	Referenz
2026-09-24	cost_rate: Kritisch 5 → 7,5, Riskant 7,5 → 10 · correction_rate: Kritisch 1 → 3 · wear_cost: Kritisch 100 → 150 · service_cost_rate: Riskant 7,5 → 10	CU-123wka4jp4w
2026-08-28	Einreichungsquoten: Kritisch 125 → 160, Riskant 140 → 180	CU-86cbb7jnp
2026-07-08	Einreichungsquoten: Kritisch 25/25 → 125, Riskant 45/40 → 140	„Adjust KPI rules"
2026-07-06	ordinary_wear_violated auf Operator < umgestellt	„Adjust seeder"
2026-06-24	Initiales Seeding der 7 Regeln	„seed the four Händler-KPI evaluation rules" ff.