Tutorial P2P - Fehlermuster Bestelländerung (Rework)

TL;DR
Ziel: Nachträgliche Änderungen an bereits angelegten Bestellungen synthetisch erzeugen.
Voraussetzungen: Die bisherigen Simple-Use-Cases wurden auf dem P2P-Basismodell aufgebaut.
Ergebnis: Exakt 15 % der Cases erhalten eine Bestelländerung mit dem Timestamp bestellung_geaendert_am.

Fachliche Fragestellung

Bestellungen werden in realen P2P-Prozessen nicht immer einmal angelegt und anschließend unverändert abgewickelt.

Typische Ursachen für Änderungen sind beispielsweise:

• geänderte Mengen,
• Preisänderungen,
• Anpassungen von Lieferterminen,
• falsche Bestelldaten,
• oder nachträglich geänderte Anforderungen.

Eine interessante Process-Mining-Frage lautet daher:

Wie häufig werden Bestellungen nach ihrer ursprünglichen Anlage nochmals bearbeitet und welchen Einfluss hat das auf den weiteren Prozess?

Für dieses Szenario verwenden wir das Rework-Behaviour der Smart Data Forge.

Gewünschtes Datenbild

Im normalen Prozess entsteht eine Bestellung einmal:

Bestellung angelegt

→ weitere Verarbeitung

In einem Rework-Fall entsteht zusätzlich ein späterer Änderungszeitpunkt:

Bestellung angelegt

→ Bestellung geändert

→ weitere Verarbeitung

Die ursprüngliche Bestellung bleibt erhalten. Zusätzlich wird über:

bestellung_geaendert_am

sichtbar, dass eine erneute Bearbeitung stattgefunden hat.

1. Rework-Regel anlegen

Öffne: 04 Special Behaviour

und füge eine neue Add deviation rule hinzu.

Wähle:

Type:
Rework (duplicate a slot)

Slot to rework:

bestellung

Die drei wichtigen Rework-Einstellungen

Beim Rework können wir drei unterschiedliche Aspekte steuern.

• Change timestamp
  Hier wird festgelegt, welcher Timestamp die Nachbearbeitung dokumentiert.
  Für unseren Use Case verwenden wir: bestellung_geaendert_am
  Die bestehende Bestellung erhält dadurch einen zusätzlichen Änderungszeitpunkt.
• Duplicate stages
  Mit dieser Option kann die Smart Data Forge eine tatsächliche zusätzliche Wiederholung erzeugen.
  Das ist beispielsweise sinnvoll, wenn eine Aktivität im Event Log wirklich erneut vorkommen soll.
• Shift downstream
  Mit dieser Option wird die durch das Rework verursachte zusätzliche Zeit an die nachfolgenden Prozessschritte weitergegeben.
  Ist die Bestellung beispielsweise sechs Stunden später fertig bearbeitet, verschieben sich auch die danach liegenden Aktivitäten entsprechend nach hinten.

Diese drei Einstellungen erlauben unterschiedliche Rework-Szenarien:

Nur Änderung dokumentieren:
Change timestamp setzen, Duplicate stages aus, Shift downstream aus.

Echte Wiederholung erzeugen:
Duplicate stages aktivieren.

Änderung mit Prozessauswirkung erzeugen:
Change timestamp setzen und Shift downstream aktivieren.

Für unser P2P-Beispiel verwenden wir die dritte Variante.

2. Änderungstimestamp auswählen

Wähle als:

Change timestamp

bestellung_geaendert_am

Dieser Timestamp ist bereits in der Tabelle bestellung enthalten.

Damit können wir später eindeutig unterscheiden:

Normale Bestellung:
bestellung_geaendert_am = NULL

Bestellung mit Rework:
bestellung_geaendert_am enthält einen Zeitpunkt.

3. Rework-Abstand definieren

Setze als:

Rework gap (minutes):

120-720

Damit findet die Änderung zwischen:

2 Stunden und 12 Stunden

nach dem ursprünglichen Vorgang statt.

Diese Werte entsprechen der bestehenden P2P-Demo-Konfiguration.

4. Wahrscheinlichkeit auf 15 % setzen

Setze:

Probability (%): 15

Aktiviere zusätzlich:

exactly N % (fixed rate)

Da wir im Tutorial mit:

500 Cases

arbeiten, bedeutet das:

15 % von 500 = exakt 75 Cases

Es entstehen also reproduzierbar 75 Rework-Fälle.

Das unterscheidet diesen Use Case vom Maverick Buying. Dort haben wir eine normale Wahrscheinlichkeit verwendet. Hier möchten wir bewusst eine stabile Fallzahl erzeugen, die sich später einfach überprüfen lässt.

5. Rework-Verhalten festlegen

Für unseren Bestelländerungs-Use-Case verwenden wir:

Change timestamp:
bestellung_geaendert_am

Duplicate stages:
deaktiviert

Shift downstream:
aktiviert

Damit wird keine zweite Bestellung erzeugt. Stattdessen erhält die bestehende Bestellung einen Änderungszeitpunkt und die zusätzliche Bearbeitungszeit wirkt sich auf die nachfolgenden Prozessschritte aus.

Vereinfacht entsteht:

Bestellung angelegt

→ Bestellung geändert

→ Bestellposition

→ Wareneingang

→ weitere Verarbeitung

6. Abweichung kennzeichnen

Setze als:

Tag:

BESTELLAENDERUNG

Die fertige Regel

Was verändert Rework im Prozess?

Der entscheidende Unterschied zu den bisherigen Use Cases ist:

Beim Maverick Buying wurde ein Teil des vorgesehenen Prozesses nicht ausgeführt.

Bei der Lieferantenperformance wurde der Prozess langsamer.

Beim Rework wird nun ein bereits bearbeitetes Objekt erneut verändert.

Fachlich lässt sich der Zusammenhang so darstellen:

Bestellung angelegt

→ Änderungsbedarf

→ Bestellung geändert

→ zusätzliche Prozesszeit

→ nachgelagerte Aktivitäten verschieben sich.

Was sollte ich später in Noreja sehen?

Im Datensatz sollten exakt 75 der 500 Cases einen gefüllten:

bestellung_geaendert_am

besitzen.

In einer Process-Mining-Analyse können daraus beispielsweise folgende Fragestellungen entstehen:

Wie häufig treten Bestelländerungen auf?

Wie unterscheidet sich die Durchlaufzeit von Bestellungen mit und ohne Änderung?

Gibt es Lieferanten, Produktgruppen oder Anforderer, bei denen Rework häufiger auftritt?

Welche nachgelagerten Prozessabschnitte werden durch die Änderung verzögert?

Interessant ist dabei insbesondere der Vergleich:

Cases ohne Rework

gegen

Cases mit Rework

Da die nachfolgenden Zeiten mitverschoben werden, sollte Rework auch einen messbaren Effekt auf die Gesamtdurchlaufzeit haben.

Rework ist nicht gleich Wrong Order

Bei Rework ist die ursprüngliche Reihenfolge fachlich korrekt. Ein Objekt wird lediglich später nochmals bearbeitet.

Beispiel:

Bestellung angelegt

→ Bestellung geändert

Bei Wrong Order wird dagegen die eigentliche Reihenfolge von Prozessereignissen verletzt.

Beispiel:

Bestellung angelegt

→ erst danach die eigentlich vorher erforderliche Freigabe.

Diesen Unterschied modellieren wir im nächsten Use Case.

Typische Fehler / darauf achten

exactly N % aktivieren.
Ohne diese Option würden 15 % lediglich als Wahrscheinlichkeit pro Case interpretiert.

Rework gap wird in Minuten angegeben.
120-720 entspricht 2–12 Stunden.

Duplicate stages nicht automatisch aktivieren.
Die Option wird nur benötigt, wenn tatsächlich eine weitere Wiederholung als zusätzliche Zeile erzeugt werden soll.

Shift downstream bewusst wählen.
Ist die Option aktiviert, wirkt sich die zusätzliche Rework-Zeit auch auf den weiteren Prozess aus.

Ergebnis

Unser synthetischer Datensatz enthält nun drei unterschiedliche Arten von Prozessauffälligkeiten:

Maverick Buying
→ ein vorgesehener Prozesszweig wird umgangen.

Schlechte Lieferantenperformance
→ Prozessschritte benötigen systematisch länger.

Bestelländerung / Rework
→ ein bereits bearbeitetes Objekt wird nachträglich erneut verändert.

Damit wird das Datenbild zunehmend realistischer und ermöglicht später unterschiedliche Arten von Ursachen- und Performance-Analysen.

Nächster Schritt

Als Nächstes erzeugen wir eine echte Verletzung der erwarteten Ereignisreihenfolge:

Bestellung vor finaler Freigabe

Dafür verwenden wir Wrong order und erzeugen in exakt 5 % der Cases eine Bestellung, deren Zeitpunkt vor der erforderlichen finalen Freigabe liegt.

Weiter: Purchase-to-Pay Fehlermuster Bestellung vor finaler Freigabe - Wrong Order