Ampel-Logik: Von KPI-Werten zur Prüfungsintensität

Explanation · Stand: 2026-09-22

Warum Ampel-Bänder statt eines gewichteten Scores?

Ein früher Entwurf sah einen gewichteten Gesamtscore vor (jede KPI normalisiert auf 0–1, mit Gewichten gemittelt, plus harte Gates). Umgesetzt wurde stattdessen eine Ampel-Klassifikation, aus drei Gründen:

Erklärbarkeit. „Händler ist Riskant, weil die Korrektur-Quote über 5 % liegt" ist für Fachbereich und Händler nachvollziehbar. Ein Score von 0,63 ist es nicht.
Keine Verrechnung. Bei einem gewichteten Mittel kann ein sehr guter Wert einen sehr schlechten ausgleichen. Genau das ist unerwünscht: Ein einzelner riskanter Befund soll durchschlagen.
Einfache Pflege. Zwei Grenzwerte pro KPI (statt Gewicht + Normalisierungs- bereich + Gate) sind fachlich diskutierbar und per Kommando änderbar.

Die drei Stufen

Jeder KPI-Wert wird gegen seine Regel geprüft und landet in genau einem Band:

Band	Bedeutung
Unauffällig (`inconspicuous`)	Wert unter allen Grenzen — kein Befund
Kritisch (`critical`)	Warnstufe — auffällig, aber allein kein Alarm
Riskant (`risky`)	Höchste Stufe — schlägt direkt auf das Cluster durch

Geprüft wird immer zuerst die Riskant-Grenze (die strengere), dann die Kritisch-Grenze. Eine fehlende Grenze überspringt das jeweilige Band — so gibt es KPIs, die nur „unauffällig oder riskant" kennen.

Namenskonvention im Code: Die Spalte critical_threshold enthält die Riskant-Grenze, risky_threshold die Kritisch-Grenze. Die englischen Namen sind nach Schweregrad sortiert (critical = am schwersten), die deutschen Fachbegriffe leider umgekehrt. Bei Regeländerungen genau hinschauen.

Zwei Blickwinkel: Händler und Servicefall

Jede Bewertung betrachtet zwei getrennte Bereiche:

Händler (scope='supplier'): die gespeicherten, periodisch vom Portal gelieferten KPIs des Händlers (Kostenquote, Einreichungsquoten, Korrektur-Quote). Sie beschreiben Verhalten über Zeit.
Servicefall (scope='service'): die im Request mitgelieferten KPIs des konkreten Falls (Verschleißkosten, Fall-Kostenquote, gewöhnlicher Verschleiß). Sie beschreiben den Einzelfall.

Beide Bereiche werden getrennt zu je einem Cluster verdichtet (Cluster-Regeln):

mindestens ein KPI Riskant oder mindestens zwei KPIs Kritisch → Cluster Riskant
sonst mindestens ein KPI Kritisch → Cluster Kritisch
sonst → Cluster Unauffällig

Ein einzelner riskanter Befund reicht also für ein riskantes Cluster; zwei Warnstufen zusammen ebenfalls.

Die Prüfungsintensitäts-Matrix

Die beiden Cluster werden über eine feste Matrix gekreuzt (Zeilen = Servicefall, Spalten = Händler):

	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 %

Lesart: Ein riskanter Befund auf einer der beiden Seiten erzwingt 100 % Prüfungsintensität. Ein kritischer Servicefall wiegt schwerer (50 %) als ein kritischer Händler bei unauffälligem Fall (25 %) — der Einzelfall liegt ja konkret auf dem Tisch, die Händler-Historie ist nur Kontext.

Der Service gibt ausschließlich diesen Prozentwert zurück. Was daraus folgt, entscheidet der Konsument — das Portal interpretiert ihn als Stichproben-Wahrscheinlichkeit: Bei X % Prüfungsintensität landet der Fall mit X % Wahrscheinlichkeit in der manuellen Prüfung, sonst in der Auto-Freigabe (siehe Architektur-Überblick).

Vollständigkeit statt Teilbewertung

Fehlt für eine anwendbare Regel der zugehörige KPI-Wert (kein gespeicherter Händler-Wert bzw. kein Payload-Wert), wird nicht teilbewertet, sondern das Ergebnis ist incomplete — ohne Cluster, ohne Prozentwert. Eine Bewertung auf lückenhafter Basis wäre schlimmer als keine: Sie würde Verlässlichkeit vortäuschen. Siehe Incomplete-Ergebnisse debuggen.

Aktualität der Händler-Werte

Händler-KPIs sind je Messperiode versioniert. Es zählt immer der jüngste, nicht abgelöste Wert je KPI — ein Verfallsdatum haben die Werte bewusst nicht: Liefert das Portal keine neuen Perioden, bleibt der letzte Stand wirksam, statt dass Bewertungen plötzlich incomplete werden. Abgelöste Werte werden nach 90 Tagen endgültig gelöscht.