Detecting Gaming & Fraud: Wie Sie Manipulationen im Entscheidungsprozess aufdecken
Wo gemessen wird, wird getrickst. Dieser Artikel zeigt, wie Sie mit forensischen Abfragen „Fake Speed“, Prozess-Umgehung und Daten-Vertuschung in Ihrem Decision-Log sichtbar machen.
Detecting Gaming & Fraud: Wie Sie Manipulationen im Entscheidungsprozess aufdecken
Autor: Heiko Meyer | Thema: Audit, Compliance & System-Hygiene
Es gibt ein ehernes Gesetz im Management, bekannt als Goodhart’s Law:
„Sobald eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein.“
Im Decision-OS messen wir die Geschwindigkeit von Entscheidungen (Time-to-Decision, TtD) und die Stabilität (Re-Open-Rate).
Das ist mächtig. Aber es schafft auch Anreize zur Manipulation.
Ein cleverer Manager könnte denken:
- „Ich will eine niedrige TtD? Dann entscheide ich einfach triviale Dinge sofort.“
- „Ich will keine Re-Opens? Dann verbiete ich meinem Team, Fehler zuzugeben.“
Wenn Sie Governance als Betriebssystem betreiben, brauchen Sie eine „Interne Revision“ – nicht aus Misstrauen, sondern zur Qualitätssicherung.
Dieser Artikel beschreibt die forensischen Abfragen, mit denen Sie „System-Gaming“ und Prozess-Betrug technisch aufdecken.
1. The Speed Trap: Erkennung von „Fake Speed“
Eine extrem niedrige Time-to-Decision (< 1 Tag) sieht im Dashboard toll aus. Aber oft ist sie ein Indikator für Schlampigkeit oder die „Salami-Taktik“ (Zerlegen einer schweren Entscheidung in harmlose Häppchen).
Der Audit-Filter (Der „Blind Spot Check“):
Suchen Sie in Ihrer Datenbank nach Anomalien am unteren Rand der Skala.
Die Abfrage (SQL-Logik):
SELECT * FROM Decisions
WHERE TtD_Hours < 24
AND Impact IN ('High', 'Strategic');
Das Verdachtsmoment:
Eine strategische Entscheidung, die in unter 24 Stunden getroffen wurde, ist verdächtig.
- Wurden Stakeholder (Consulted) wirklich gehört?
- Wurde die Definition of Ready eingehalten?
- Oder wurde das Ticket erst nach der Entscheidung angelegt („Reverse Engineering“), nur um das Log zu füllen?
2. The Bypass: Erkennung von Prozess-Umgehung
Der häufigste Governance-Bruch ist der manuelle Eingriff. Ein Manager hat keine Lust auf
Diskussionen und setzt den Status einfach direkt auf DECIDED, ohne die Phasen
DRAFT oder READY zu durchlaufen.
Der Audit-Filter:
Analysieren Sie die Transition History des Tickets.
Die Logik:
Prüfen Sie Tickets, bei denen der Zeitstempel Created_At nahezu identisch mit
Decided_At ist, aber keine Automatisierung (Async Review) lief.
-
Warnsignal: Status-Sprünge wie
DRAFT → DECIDED(unter Umgehung vonREADY). - Die Konsequenz: Diese Entscheidungen sind oft nicht exekutierbar, da die Execution Owner nicht informiert wurden. Im Decision-OS gilt dies als „Cheat“ und taucht negativ in der Decision Hygiene Scorecard auf.
3. The Consensus-Fake: Erkennung von „Consulted-Inflation“
Unsichere DRIs (Directly Responsible Individuals) versuchen oft, Verantwortung zu diffundieren,
indem sie halb Japan in cc setzen. Sie missbrauchen das Feld Consulted, um sich
abzusichern.
Der Audit-Filter:
Suchen Sie nach „Masse statt Klasse“.
Die Abfrage:
Finden Sie alle Tickets, bei denen Count(Consulted_Users) > 3 ist.
Im Decision-OS gilt die technische „Rule of 3“. Wer mehr Leute einbinden will, muss dies im Feld
Rationale begründen.
Wenn das Feld leer ist, aber 10 Leute konsultiert wurden, haben Sie keine Entscheidung, sondern eine Volksabstimmung. Das System sollte hier eine Warnung flaggen.
4. The Ghost Deletion: Erkennung von Vertuschung
Was passiert, wenn eine Entscheidung falsch war? In schlechten Kulturen wird das Ticket gelöscht.
Das darf ein Audit-sicheres System niemals erlauben.
Die Tech-Spec:
- Hard Delete: Muss für normale User technisch deaktiviert sein.
- Soft Delete: Status
KILLEDist der einzige Weg, eine Entscheidung zu beenden.
Der Audit-Filter:
Überwachen Sie die „Graveyard“-Liste. Eine gesunde Organisation hat eine Strategic Kill-Rate von 15–20 %.
- Alarm: Wenn Ihre Kill-Rate bei 0 % liegt, betreibt Ihre Organisation „Watermelon Reporting“ (außen grün, innen rot). Sie verstecken die Leichen im Keller, statt sie zu beerdigen.
Fazit: Vertrauen ist gut, Telemetrie ist besser
Diese Audit-Routinen sind nicht dazu da, Mitarbeiter zu bestrafen. Sie sind dazu da, die Integrität der Daten zu schützen.
Denn denken Sie an das Ziel: Wir bauen den Trainingsdatensatz für die KI.
Wenn wir zulassen, dass „Fake-Daten“ (manipulierte Entscheidungen) in das Log kommen, vergiften wir unser eigenes künftiges Gehirn (Data Poisoning).
Gute Governance schützt das System vor dem Ego der Nutzer.
Deep Dive:
Sie wollen die komplette Audit-Checkliste für den monatlichen Gesundheits-Check Ihrer Governance?
Wir haben die Decision Hygiene Scorecard entwickelt, die genau diese Anomalien abfragt.
Sie finden die Scorecard in Anhang D (Tabelle D.4) des Handbuchs Decision-OS.
👉 [Link zum Buch-Download]
Governance-Metriken schützen – statt sie unbewusst zu vergiften
Viele Organisationen führen KPIs wie Time-to-Decision, Re-Open-Rate oder Kill-Rate ein – und gehen davon aus, dass das Messen alleine schon zur Verbesserung führt. In der Praxis passiert oft das Gegenteil: Teams lernen, wie man Kennzahlen „schönrechnet“, ohne das Verhalten zu ändern.
Genau hier entscheidet sich, ob Ihr Governance-System zur Entscheidungs-Hygiene beiträgt oder zu einer neuen Variante des „Greenwashing“ wird. Ohne forensische Checks erkennen Sie nicht, ob niedrige TtD-Werte echte Geschwindigkeit oder nur Fake Speed sind.
Decision-OS behandelt Metriken deshalb wie kritische Infrastruktur: Jede Kennzahl wird von Audit-Routinen begleitet – vom Blind Spot Check für High-Impact-Entscheidungen bis zur Überwachung von Kill-Rate und Status-Sprüngen in der History.
Das Ziel ist nicht Kontrolle um der Kontrolle willen, sondern die Integrität des Datensatzes. Denn auf diesem Datensatz werden künftig Ihre Reporting-Systeme und AI-Assistenten trainiert. Schlechte Governance ist damit nicht nur ein Führungs-, sondern ein Datenqualitätsproblem.