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 Braunauffä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

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