--- title: "Tutorial P2P Expert - XOR; unterschiedliche Beschaffungswege" url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-expert-xor-unterschiedliche-beschaffungswege" language: "de" last_updated: "2026-09-22T10:42:54.338Z" --- # Tutorial P2P Expert - XOR; unterschiedliche Beschaffungswege Von einem einheitlichen P2P-Prozess zu unterschiedlichen Prozesspfaden für physische Materialien und Software. > **TL;DR** > **Ziel:** Nach der Bestellposition unterschiedliche Beschaffungspfade für physische Materialien und Software erzeugen. > **Voraussetzungen:** `Config 2 – Simple` ist vorhanden und die bisherigen Simple-Use-Cases sind konfiguriert. > **Ergebnis:** Physische Beschaffungen durchlaufen Lieferung, Warenannahme und Wareneingang, während Software direkt bereitgestellt wird. ## Fachliche Fragestellung Nicht jede Bestellung durchläuft denselben Beschaffungsprozess. Ein physisches Bauteil muss beispielsweise: `geliefert` → `angenommen` → `gebucht` → `geprüft` werden. Bei einer Softwarelizenz gibt es dagegen keinen klassischen Wareneingang. Der entsprechende Ablauf kann deutlich kürzer sein: `Bestellposition` → `Bereitstellung` Eine zentrale Process-Mining-Frage lautet deshalb: **Wie unterscheiden sich Durchlaufzeiten und Prozessmuster zwischen verschiedenen Beschaffungsarten?** ## Gewünschtes Datenbild Nach der: `bestellposition` soll eine XOR-Entscheidung zwischen zwei Prozesspfaden stattfinden. ### Physische Beschaffung `Bestellposition` → `Lieferung` → `Warenannahme` → `Wareneingang` → `Wareneingangsprüfung` → `Rechnung` ### Software-Beschaffung `Bestellposition` → `Bereitstellung` → `Rechnung` Danach laufen beide Varianten wieder im gemeinsamen Rechnungs- und Zahlungsprozess weiter. ## 1\. Auf `Mode: Expert` wechseln Stelle die Smart Data Forge auf: `Mode: Expert` Dadurch werden später zusätzlich die Bereiche: `07 Capacity Bottleneck` und `08 Bundling` verfügbar. Die eigentliche Branch-Logik wird weiterhin in: `03 Causal Chain` modelliert. ## 2\. Zusätzliche Tabellen anlegen Für die beiden Beschaffungspfade erweitern wir das Simple-Modell um folgende Tabellen: ### `lieferung` **Primary Key:** `lieferung_id` **Timestamp:** `geliefert_am` **Foreign Key:** `bestellposition_id → bestellposition.position_id` ### `warenannahme` **Primary Key:** `warenannahme_id` **Timestamp:** `angenommen_am` **Foreign Key:** `lieferung_id → lieferung.lieferung_id` ### `bereitstellung` **Primary Key:** `bereitstellung_id` **Timestamp:** `bereitgestellt_am` **Foreign Key:** `bestellposition_id → bestellposition.position_id` ### `wareneingang_pruefung` **Primary Key:** `pruefung_id` **Timestamps:** `pruefung_geplant_am`, `wareneingang_geprueft_am` **Foreign Key:** `wareneingang_id → wareneingang.wareneingang_id` Diese Tabellen bilden die fachlichen Unterschiede zwischen einem physischen und einem digitalen Beschaffungsprozess ab. ## 3\. PHYSICAL-Pfad aufbauen ![](https://cdn-assets.productfruits.com/12fc532a-c92a-46a1-a8f1-52f201b69c5e) Öffne: `03 Causal Chain` Nach: `bestellposition` fügen wir zunächst: `lieferung` ein. Öffne anschließend bei `lieferung`: `Branch / Join` und konfiguriere: **Parent slot:** `bestellposition` **Branch tag:** `PHYSICAL` Aktiviere zusätzlich: `XOR-Split` Damit wird `lieferung` zum Ausgangspunkt der Entscheidung zwischen physischer Beschaffung und Software. ## 4\. Branch-Gewichtung konfigurieren Für unser Demo verwenden wir: `PHYSICAL = 80` `SOFTWARE = 20` Damit laufen ungefähr 80 % der entsprechenden Fälle über den physischen Prozess und 20 % über den Software-Pfad. Die Smart Data Forge unterstützt dafür gewichtete XOR-Branches direkt in der `Causal Chain`. ## 5\. Physische Prozesskette ergänzen Nach `lieferung` ergänzen wir: `warenannahme` → `wareneingang` → `wareneingang_pruefung` Alle diese Slots gehören zum: `PHYSICAL` Branch. Die im Expert-Modell verwendeten Zeitabstände sind: | Übergang | Zeit | | --- | --- | | `bestellposition → lieferung` | 2–10 Tage | | `lieferung → warenannahme` | 0–1 Tag | | `warenannahme → wareneingang` | 1–6 Stunden | | `wareneingang → wareneingang_pruefung` | 0–2 Tage | Damit entsteht ein realistischer physischer Materialfluss von der Bestellung bis zur Qualitätsprüfung. ## 6\. SOFTWARE-Pfad ergänzen ![](https://cdn-assets.productfruits.com/593e2377-e2fc-421c-87c9-e445b75f8790) Als zweiten Branch fügen wir: `bereitstellung` hinzu. Konfiguriere: **Parent slot:** `bestellposition` **Branch tag:** `SOFTWARE` Der Software-Pfad ist damit deutlich kürzer: `Bestellposition` → `Bereitstellung` Für die Bereitstellung verwenden wir einen Abstand von:`0–4 Stunden` Damit simulieren wir beispielsweise die Bereitstellung einer Lizenz oder eines digitalen Zugangs. ## Wie entscheidet die Forge zwischen beiden Pfaden? Die XOR-Entscheidung wird bereits vor der eigentlichen Case-Generierung getroffen. Für einen Case ist deshalb eindeutig festgelegt, welcher Branch aktiv ist. Nur die Slots des gewählten Branches werden erzeugt. Die Slots des anderen Branches fehlen für diesen Case. Ein Case besitzt dadurch entweder: `lieferung / warenannahme / wareneingang / wareneingang_pruefung` oder: `bereitstellung` aber nicht beide Pfade gleichzeitig. ## Beschaffungsart auch in den Daten sichtbar machen Im Expert-Demo wird die getroffene XOR-Entscheidung zusätzlich auf ein fachliches Attribut übertragen. Dazu wird: `bestellung.produktgruppe` auf: `PHYSICAL` oder: `SOFTWARE` gesetzt. Die Smart Data Forge unterstützt dafür bei einem XOR-Split das Schreiben des ausgewählten Branch-Werts auf einen bereits erzeugten Datensatz. Damit lässt sich später nicht nur am Prozesspfad, sondern auch über ein Attribut erkennen, zu welcher Beschaffungsart der Case gehört. ## Materialien passend zum Branch Im vorbereiteten Expert-Datensatz ist zusätzlich sichergestellt, dass die ausgewählten Materialien zum jeweiligen Prozesspfad passen. Beispiele: **PHYSICAL** `Steuerungsmodul`, `Kabelsatz`, `Gehäuse`, `Sensor` **SOFTWARE** `Standardlizenz,`, `Wartungsvertrag` Damit soll verhindert werden, dass beispielsweise eine `Standardlizenz` durch einen physischen Wareneingangsprozess läuft. Diese Zuordnung ist in der vorbereiteten Expert-Konfiguration bereits enthalten und muss für das Training nicht manuell aufgebaut werden. ## Was sollte ich später in Noreja sehen? Im Process Mining sollten nun zwei deutlich unterschiedliche reguläre Varianten sichtbar werden. ### Physischer Pfad `Bestellposition` → `Lieferung` → `Warenannahme` → `Wareneingang` → `Wareneingangsprüfung` ### Software-Pfad `Bestellposition` → `Bereitstellung` Interessante Analysefragen sind beispielsweise: **Welche Beschaffungsart besitzt die längere Durchlaufzeit?** **An welcher Stelle entsteht bei physischen Bestellungen die meiste Wartezeit?** **Wie stark unterscheiden sich Software- und Materialbeschaffung im Prozess?** Wichtig ist: Diese Unterschiede sind **keine Abweichungen**. Beide Pfade sind reguläre Prozessvarianten unseres P2P-Modells. ## Prozessvariante vs. Abweichung Die bisherigen Simple-Use-Cases haben bewusst Auffälligkeiten erzeugt. Zum Beispiel: `Maverick Buying` `Rework` `Wrong Order` Bei: `PHYSICAL` und: `SOFTWARE` handelt es sich dagegen um **fachlich vorgesehene Varianten**. Das ist für die spätere Process-Mining-Analyse wichtig: Nicht jede unterschiedliche Variante ist automatisch ein Prozessproblem. ## Typische Fehler / darauf achten **Beide Pfade vom gleichen Ausgangspunkt starten.** Sowohl `lieferung` als auch `bereitstellung` beziehen sich auf `bestellposition`. **Gleiche Branch-Tags verwenden.** Der physische Pfad erhält durchgehend `PHYSICAL`, der Software-Pfad `SOFTWARE`. **XOR statt AND verwenden.** Ein Case soll genau einen der beiden Beschaffungspfade durchlaufen. **Varianten nicht als Abweichung interpretieren.** PHYSICAL und SOFTWARE sind reguläre fachliche Prozessvarianten. ## Ergebnis Unser bisheriges P2P-Modell besitzt nun zwei reguläre Beschaffungspfade: `PHYSICAL` → längerer logistischer Prozess mit Lieferung und Wareneingang. `SOFTWARE` → kurze digitale Bereitstellung. Damit können wir erstmals untersuchen, wie unterschiedliche fachliche Prozesspfade die spätere Durchlaufzeit beeinflussen. ## Nächster Schritt Im nächsten Expert-Use-Case konzentrieren wir uns auf den physischen Pfad. Dort führen wir mit: `wareneingang_pruefung` eine Aktivität ein, deren Bearbeitungskapazität begrenzt ist. Darauf aufbauend erzeugen wir einen echten: **Capacity Bottleneck mit Backlog.** **Weiter:** [**Tutorial P2P Expert -  Kapazitätsengpass**](https://docs.noreja.com/de/article/noreja-smart-data-forge-p2p-expert-kapazitatsengpass)