---
title: "Tutorial P2P - Fehlermuster Bestellung vor finaler Freigabe - Wrong Order"
url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-bestellung-vor-finaler-freigabe-wrong-order"
language: "de"
last_updated: "2026-09-22T08:56:55.772Z"
---

# 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`

![](https://cdn-assets.productfruits.com/29da7638-f8f1-441f-97ca-1a4459f1802d)

## 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`

![](https://cdn-assets.productfruits.com/49aa8db0-b78e-4861-932d-ff3ec1edb5e0)

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

| Einstellung | Wert |
| --- | --- |
| Type | `Wrong order` |
| Slot A | `freigabe_b` |
| Swap with | `bestellung` |
| Probability | `5 %` |
| Tag | `BESTELLUNG_VOR_FINALER_FREIGABE` |

## 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**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-prozessabbruch)