Tutorial P2P Expert XOR - unterschiedliche Beschaffungswege

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

Ö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:

Damit entsteht ein realistischer physischer Materialfluss von der Bestellung bis zur Qualitätsprüfung.

6. SOFTWARE-Pfad ergänzen

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