--- title: "Tutorial P2P - Fehlermuster Maverick Buying (Skip)" url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-maverick-buying-skip" language: "de" last_updated: "2026-09-22T08:53:47.661Z" --- # Tutorial P2P - Fehlermuster Maverick Buying (Skip) > **TL;DR** > **Ziel:** Fälle erzeugen, in denen bestimmte Anforderer einen eigentlich vorgesehenen Freigabeweg umgehen. > **Voraussetzungen:** `Config 1 – Basis` ist geladen und die Freigabelogik mit `DUAL`\- und `DIRECT`\-Pfad ist vorhanden. > **Ergebnis:** Für die Anforderer `Kaya` und `Braun` wird in 80 % der dafür relevanten Fälle der vorgesehene `DUAL`\-Freigabezweig übersprungen und die Abweichung gekennzeichnet. ## Fachliche Fragestellung Eine typische Compliance-Frage im Purchase-to-Pay-Prozess lautet: **Werden Bestellungen durchgeführt, obwohl die für diesen Vorgang vorgesehene Freigabe umgangen wurde?** Dieses Verhalten wird häufig unter **Maverick Buying** betrachtet. Für unser synthetisches Beispiel nehmen wir an, dass insbesondere die Anforderer: `Kaya` und `Braun`auffällig sind. Wenn für einen ihrer Vorgänge der reguläre `DUAL`\-Freigabeweg vorgesehen wäre, soll dieser in einem Teil der Fälle bewusst umgangen werden. ## Gewünschtes Datenbild Im normalen Fall sieht der Prozess vereinfacht so aus: `bestellanforderung` → `freigabe_a` + `freigabe_b` → `bestellung` Im Maverick-Buying-Fall soll dagegen entstehen: `bestellanforderung` → `bestellung` obwohl für diesen Case ursprünglich der `DUAL`\-Freigabeweg vorgesehen war. Die beiden Freigabeobjekte fehlen in diesem Fall. Genau dieses fehlende Prozessmuster soll später in Noreja sichtbar werden. ## Wichtig: `DIRECT` ist nicht automatisch Maverick Buying Unsere `Causal Chain` besitzt bereits einen regulären `DIRECT`\-Pfad. Das bedeutet: Ein Case, für den die XOR-Entscheidung von Anfang an `DIRECT` auswählt, ist **keine Abweichung**. Der direkte Weg gehört zum vorgesehenen Prozessmodell. Maverick Buying entsteht erst dann, wenn: - für den Case eigentlich `DUAL` ausgewählt wurde, - der Case damit den Freigabeweg durchlaufen sollte, - eine zusätzliche Regel diesen Freigabeweg anschließend gezielt überspringt. Diese Unterscheidung ist wichtig, weil wir später in der Analyse zwischen **zulässiger Prozessvariante** und **unerwünschter Abweichung** unterscheiden möchten. ## Warum verwenden wir `Team bypass`? Öffne: `04 Special Behaviour` Die Smart Data Forge bietet dort unter anderem: `Overjump (skip a slot)` und `Team bypass (skip a branch for matching cases)` an. Fachlich ist unser Maverick-Buying-Szenario ein **Übergehen der Freigabe**. Technisch verwenden wir hier jedoch `Team bypass`, weil nicht nur ein einzelner Slot übersprungen werden soll, sondern der komplette `DUAL`\-Branch mit seinen Freigaben. `Team bypass` kann dafür einen Branch anhand eines Branch-Owners identifizieren und diesen für Cases überspringen, die eine bestimmte Bedingung erfüllen. ## 1\. Neue Abweichungsregel anlegen ![](https://cdn-assets.productfruits.com/360fc317-2742-4ac6-a1c6-65f63bd9cc22) Wähle unter `Add deviation rule`: **Type:** `Team bypass (skip a branch for matching cases)` ## 2\. Ausgangspunkt der Bedingung  Als Ziel verwenden wir:  `bestellanforderung` Die Bedingung soll auf einem Attribut dieses Objekts ausgewertet werden. In unserem Beispiel ist das: `anforderer` Damit können wir das Prozessverhalten direkt von einem fachlichen Datenattribut abhängig machen. Das ist ein zentraler Unterschied zu einer rein zufälligen Abweichung: Nicht irgendein Case umgeht die Freigabe, sondern das Verhalten wird gezielt mit bestimmten Anforderern verbunden. ## 3\. Den zu überspringenden Branch definieren Als `Branch owner` wählen wir: `freigabe_a` `freigabe_a` ist Teil des Branches mit dem Tag: `DUAL` Die Engine verwendet diesen Branch-Owner, um den zugehörigen Branch zu bestimmen. Wenn die Bypass-Regel greift, werden die Slots dieses Branches für den betreffenden Case übersprungen. Damit verschwinden im entsprechenden Case die vorgesehenen Freigabeschritte aus der Prozessausführung. ## 4\. Bedingung auf den Anforderer setzen Konfiguriere die Bedingung: **Column:** `anforderer` **Operator:** `in` **Value:** `Kaya, Braun` Bei `in` interpretiert die Smart Data Forge die kommaseparierten Werte als Liste. Damit gilt die Regel ausschließlich für Bestellanforderungen, deren `anforderer` entweder `Kaya` oder `Braun` ist. ## 5\. Wahrscheinlichkeit konfigurieren Setze: **Probability (%):** `80` Das entspricht der Konfiguration des vollständigen P2P-Demos. Dort ist der `Team Bypass` für `Kaya` und `Braun` ebenfalls mit einer Wahrscheinlichkeit von 80 % hinterlegt. Wichtig ist die Interpretation dieser 80 %. Sie bedeuten **nicht**, dass 80 % aller 500 Cases Maverick-Buying-Fälle werden. Die Regel kann nur greifen, wenn mehrere Bedingungen zusammenkommen: - der Anforderer ist `Kaya` oder `Braun`, - die ursprüngliche XOR-Entscheidung hat `DUAL` gewählt, - und anschließend trifft die 80-%-Wahrscheinlichkeit des `Team bypass` zu. Die Engine prüft ausdrücklich, ob der Case ursprünglich den Branch des ausgewählten Branch-Owners genommen hätte, bevor der Bypass angewendet wird. Das erzeugt ein wesentlich sinnvolleres Datenbild als eine pauschale 80-%-Abweichung über den gesamten Datensatz. ## Keine feste Quote verwenden Bei diesem Use Case übernehmen wir bewusst die Logik des bestehenden P2P-Demos: **80 % Wahrscheinlichkeit, keine feste** `**exactly N %**`**\-Quote.** Damit wird für jeden relevanten Case eine probabilistische Entscheidung getroffen. Anders als bei späteren Use Cases wie Rework oder Wrong Order wollen wir hier nicht erzwingen, dass eine exakt vorgegebene Anzahl an Fällen entsteht. Das passt auch fachlich zum Szenario: Das Verhalten bestimmter Anforderer soll eine erhöhte Wahrscheinlichkeit besitzen und keine künstlich exakt vorgegebene Fallzahl. ## 6\. Abweichung kennzeichnen Setze als `Tag`: `FREIGABE_UMGANGEN_TROTZ_SCHWELLWERT` Auch dieser Tag wird aus dem bestehenden P2P-Demo übernommen. Die Tutorial-Config ist so vorbereitet, dass solche Tags in: `bestellung.abweichung` geschrieben werden können. ## Die fertige Regel Die Konfiguration lässt sich fachlich so lesen: > Wenn der `anforderer` der Bestellanforderung `Kaya` oder `Braun` ist und der Case eigentlich über den `DUAL`\-Freigabeweg laufen würde, wird dieser Freigabezweig mit einer Wahrscheinlichkeit von 80 % umgangen. Technisch ergibt sich damit: **Target:** `bestellanforderung` **Branch owner:** `freigabe_a` **Condition:** `anforderer IN (Kaya, Braun)` **Probability:** `80 %` **Tag:** `FREIGABE_UMGANGEN_TROTZ_SCHWELLWERT` ## Was ändert sich dadurch im Datensatz? Vor der Regel hatten wir zwei reguläre Varianten: **DUAL** `Bestellanforderung → Freigaben → Bestellung` **DIRECT** `Bestellanforderung → Bestellung` Nach der Regel kommt ein drittes fachlich relevantes Muster hinzu: **Maverick Buying** Der Case wäre aufgrund der ursprünglichen Prozessentscheidung ein `DUAL`\-Case gewesen, die vorgesehenen Freigaben werden aber durch die zusätzliche Bypass-Regel nicht ausgeführt. Auf den ersten Blick kann der resultierende Aktivitätspfad daher ähnlich wie ein regulärer `DIRECT`\-Case aussehen. Der **Grund für diesen Pfad ist jedoch ein anderer**. Genau deshalb modellieren wir neben dem Prozessmuster auch die Ursache über `anforderer` und das Abweichungs-Tag. ## Was sollte ich später in Noreja sehen? In der späteren Analyse sollten sich Fälle erkennen lassen, in denen: - eine `bestellanforderung` vorhanden ist, - anschließend eine `bestellung` entsteht, - die erwarteten Freigabeaktivitäten fehlen, - und dieses Verhalten überproportional mit den Anforderern `Kaya` und `Braun` zusammenhängt. Eine interessante Analysefrage lautet daher nicht nur: **„Wie viele Bestellungen haben keine Freigabe?“** sondern: **„Welche Ursachen / Attribute erklären, warum bestimmte Bestellungen den vorgesehenen Freigabeprozess nicht durchlaufen?“** Damit wird aus einer einfachen Prozessvariante ein kausal interpretierbarer Use Case. ## Typische Fehler / darauf achten `**DIRECT**` **und Maverick Buying nicht gleichsetzen.** Ein regulärer `DIRECT`\-Case ist Bestandteil des vorgesehenen Prozessmodells. Der Maverick-Buying-Case entsteht erst durch den zusätzlichen `Team bypass`. **Nicht** `**Overjump**` **für einen einzelnen Freigabe-Slot verwenden.** Unser Freigabeprozess besteht aus einem Branch. Deshalb verwenden wir `Team bypass`, damit der komplette relevante Zweig umgangen wird. **80 % nicht als Anteil aller Cases interpretieren.** Die Wahrscheinlichkeit gilt nur für passende `Kaya`\-/`Braun`\-Cases, die ursprünglich den `DUAL`\-Branch genommen hätten. ## Ergebnis Unser bislang sauberes Basismodell enthält nun die erste gezielt erzeugte Prozessabweichung. Wir haben dabei nicht einfach zufällig Freigaben entfernt, sondern einen Zusammenhang erzeugt: `anforderer` → erhöhte Wahrscheinlichkeit eines Freigabe-Bypasses → veränderte Prozessvariante → erkennbare Abweichung in den Daten. Damit haben wir das zentrale Prinzip der Smart Data Forge erstmals praktisch angewendet: **Aus einer fachlichen Hypothese wird ein kontrolliert erzeugtes kausales Datenmuster.** ## Nächster Schritt Als Nächstes betrachten wir einen anderen Typ von Ursache. Diesmal entfernen wir keinen Prozessschritt, sondern verändern dessen **Dauer**: **Wie wirkt sich ein schlecht performender Lieferant auf die Durchlaufzeit des Beschaffungsprozesses aus?** Dazu konfigurieren wir `Globex SE` als auffälligen Lieferanten und verwenden erstmals `Conditional Rules`. **Weiter:** [**Tutorial P2P Fehlermuster schlechte Lieferperformance**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-schlechte-lieferperformance)