Tutorial P2P - Fehlermuster Bestellung vor finaler Freigabe - Wrong Order

TL;DR
Ziel: Fälle erzeugen, in denen eine Bestellung zeitlich vor einer erforderlichen Freigabe liegt.
Voraussetzungen: Die Freigabestruktur mit DUAL und DIRECT ist vorhanden.
Ergebnis: In einem Teil der freigabepflichtigen Cases liegt bestellung zeitlich vor freigabe_b.

Fachliche Fragestellung

Im regulären Beschaffungsprozess sollte eine freigabepflichtige Bestellung erst erstellt werden, nachdem die erforderlichen Freigaben erfolgt sind.

Der erwartete Ablauf lautet:

Bestellanforderung

→ Freigabe A / Freigabe B

→ Bestellung

Eine mögliche Compliance-Abweichung lautet dagegen:

Bestellanforderung

→ Bestellung

→ Freigabe B

Die Freigabe fehlt dabei nicht vollständig. Sie erfolgt lediglich zu spät.

Genau darin unterscheidet sich dieser Use Case vom Maverick Buying.

Maverick Buying vs. Wrong Order

Beim Maverick Buying wird ein vorgesehener Freigabeweg umgangen.

Bei Wrong Order findet die Freigabe weiterhin statt – allerdings in der falschen zeitlichen Reihenfolge.

Maverick Buying

Bestellanforderung → Bestellung

Freigabe wird übersprungen.

Wrong Order

Bestellanforderung → Bestellung → Freigabe

Freigabe ist vorhanden, erfolgt aber erst nach der Bestellung.

Damit erzeugen wir eine andere Art von Compliance-Problem.

1. Wrong-Order-Regel anlegen

Öffne:

04 Special Behaviour

und füge eine neue Add deviation rule hinzu.

Wähle:

Type:
Wrong order (swap two slots)

Die Smart Data Forge verwendet Wrong order, um die Zeitpunkte zweier Prozess-Slots miteinander zu vertauschen.

2. Die beiden Prozessschritte auswählen

Wähle:

Slot A:
freigabe_b

und:

Swap with:
bestellung

Damit definieren wir, welche beiden Prozessereignisse ihre zeitliche Position tauschen sollen.

Im normalen Case gilt:

freigabe_b

→ bestellung

Im Wrong-Order-Case entsteht:

bestellung

→ freigabe_b

Was wird dabei tatsächlich verändert?

Wrong order verändert nicht die relationale Struktur des Datensatzes.

Foreign Keys, Tabellenbeziehungen und die eigentliche Causal Chain bleiben bestehen.

Stattdessen werden die Timestamps der beiden ausgewählten Slots nach der normalen Datengenerierung zeitlich verschoben. Die Engine wendet solche bewusst erzeugten Wrong-Order-Anomalien erst nach der regulären kausalen Timestamp-Erzeugung an.

Dadurch erhalten wir bewusst Daten, bei denen:

die Beziehung fachlich weiterhin existiert, die zeitliche Reihenfolge aber nicht mehr plausibel ist.

Genau solche Fälle sind für Process Mining besonders interessant.

3. Wrong Order nur auf freigabepflichtige Cases anwenden

Hier müssen wir eine Besonderheit unseres P2P-Modells berücksichtigen.

freigabe_b existiert nur auf dem:

DUAL

Pfad.

Bei einem regulären:

DIRECT

Case gibt es keine freigabe_b.

Wir möchten deshalb vermeiden, dass ein DIRECT-Case als Wrong Order ausgewählt wird, obwohl dort gar keine zweite Freigabe vorgesehen ist.

Dafür setzen wir bei der Wrong-Order-Regel zunächst:

Probability (%): 5

Damit gilt:

Wenn eine freigabe_b für den Case existiert, besteht eine Wahrscheinlichkeit von 5 %, dass ihre zeitliche Reihenfolge mit der Bestellung vertauscht wird.

5. Abweichung kennzeichnen

Setze bei der Wrong-Order-Regel als:

Tag:

BESTELLUNG_VOR_FINALER_FREIGABE

Die fertige Konfiguration

Wrong-Order-Regel

Was verändert sich im Datensatz?

Ohne Abweichung:

Bestellanforderung

→ Freigabe A / B

→ Bestellung

Mit Wrong Order:

Bestellanforderung

→ Bestellung

→ Freigabe B

Wichtig ist:

Die Freigabe wurde nicht entfernt.

Sie ist weiterhin vorhanden, liegt zeitlich jedoch nach der Bestellung.

Damit erzeugen wir bewusst einen Fall, bei dem Prozessstruktur und Zeitlogik nicht mehr miteinander übereinstimmen.

Was sollte ich später in Noreja sehen?

In Noreja sollten einzelne freigabepflichtige Cases sichtbar werden, bei denen die Bestellung bereits vor der erforderlichen Freigabe erfolgt ist.

Mögliche Analysefragen sind:

Wie viele Bestellungen wurden vor Abschluss der Freigabe angelegt?

Welche Anforderer, Produktgruppen oder Bestellwerte treten bei diesen Fällen besonders häufig auf?

Welche Auswirkungen hat die falsche Reihenfolge auf den weiteren Prozess?

Besonders interessant ist dabei der Vergleich mit Maverick Buying:

Maverick Buying: Freigabe fehlt.

Wrong Order: Freigabe existiert, kommt aber zu spät.

Damit können zwei ähnlich wirkende Prozessauffälligkeiten fachlich sauber voneinander getrennt werden.

Typische Fehler / darauf achten

Wrong Order nicht mit Overjump verwechseln.
Wir wollen die Freigabe nicht entfernen, sondern lediglich ihre zeitliche Position verändern.

Nur freigabepflichtige Cases berücksichtigen.
Ein DIRECT-Case ohne freigabe_b ist kein Wrong-Order-Fall.

Die relationale Struktur bleibt bestehen.
Wrong order manipuliert die Zeitpunkte – nicht die Foreign Keys oder die Causal Chain.

Ergebnis

Unser Datensatz enthält nun zusätzlich eine echte zeitliche Prozessabweichung:

erforderliche Freigabe

→ sollte vor der Bestellung stattfinden

wird in ausgewählten Cases zu:

Bestellung

→ Freigabe

Damit haben wir neben fehlenden Aktivitäten, Performance-Problemen und Rework nun auch eine Reihenfolgeverletzung im synthetischen P2P-Datensatz.

Nächster Schritt

Als Nächstes modellieren wir Prozesse, die zwar regulär beginnen, aber nicht bis zum Ende durchlaufen:

Prozessabbruch / offene Prozesse

Dafür verwenden wir das Abort-Behaviour und lassen Cases gezielt nach unterschiedlichen Prozessschritten enden.

Weiter: Purchase-to-Pay Fehlermuster Prozessabbruch bzw. offene Prozesse