Tutorial P2P - Fehlermuster schlechte Lieferperformance
TL;DR
Ziel: Einen Lieferanten gezielt mit längeren Prozesszeiten verknüpfen.
Voraussetzungen: Das P2P-Basismodell ist geladen und der Maverick-Buying-Use-Case wurde ergänzt.
Ergebnis: Fälle mitGlobex SEerhalten längere Zeitabstände und können später hinsichtlich ihrer Durchlaufzeit mit anderen Lieferanten verglichen werden.
Fachliche Fragestellung
Eine typische P2P-Analyse lautet:
Welche Lieferanten verursachen überdurchschnittlich lange Durchlaufzeiten?
Für unser Beispiel nehmen wir an, dass der Lieferant: Globex SE eine schlechtere Performance aufweist.
Anders als beim Maverick Buying entfernen wir diesmal keinen Prozessschritt. Stattdessen bleibt der Prozesspfad unverändert, aber bestimmte Übergänge benötigen mehr Zeit.
Gewünschtes Datenbild
Zwei ansonsten vergleichbare Bestellungen sollen sich abhängig vom Lieferanten unterscheiden:
Normaler Lieferant
Bestellung → Bestellposition → Wareneingang
mit normalen Zeitabständen.
Globex SE
Bestellung → Bestellposition → Wareneingang
mit deutlich längeren Zeitabständen.
Damit bleibt die Prozessstruktur identisch. Die Ursache der längeren Durchlaufzeit steckt im Attribut: lieferant.lieferantenname
Das ermöglicht später eine Analyse wie:
„Welche Lieferanten erklären lange Durchlaufzeiten zwischen Bestellung und Wareneingang?“
Conditional Rules statt Special Behaviour
Öffne: 04 Special Behaviour
Unterhalb der Abweichungsregeln befindet sich: Conditional rules (A / C / D)
Für diesen Use Case verwenden wir: A · Timing (change gap)
Eine Timing-Regel verändert den Zeitabstand nach einer Aktivität, wenn eine definierte Bedingung erfüllt ist.
Die Causal Chain selbst bleibt dabei erhalten.
1. Timing-Regel anlegen
Wähle:
Effect:A · Timing (change gap)
Als Activity (gap after) wählen wir zunächst: bestellung
Damit wird der Übergang nach der Bestellung beeinflusst.
2. Den Lieferanten als Bedingung verwenden
Die Spalte lieferant_id der bestellung verweist auf die Referenztabelle lieferant.
Deshalb wählen wir:
Condition – source:Linked dimension (FK)
Anschließend:
FK column:lieferant_id
Dimension column:lieferantenname
Operator:=
Value:Globex SE
Damit lautet die Bedingung fachlich:
Wenn die Bestellung zum Lieferanten
Globex SEgehört, soll sich die nachfolgende Prozesszeit verändern.
3. Zeitabstand vervielfachen
Unter:
Effect on gap after the activity
wähle:
× factor
und setze:
3
Der normale Zeitabstand wird damit für passende Fälle mit dem Faktor 3 multipliziert.
Genau dieses Prinzip verwendet auch dein vollständiges P2P-Demoset: Für Globex SE sind Timing-Regeln mit gap_multiply und Faktor 3 hinterlegt.
Setze zusätzlich den Tag:
LIEFERANT_SCHLECHTE_PERFORMANCE
Was bedeutet der Faktor 3?
Der Faktor ersetzt nicht den vorhandenen Zeitabstand.
Stattdessen wird der bereits über die Causal Chain gezogene Gap vervielfacht.
Aus beispielsweise 10 Stunden werden bei Globex SE: 30 Stunden
Dadurch behalten wir die normale Streuung der Prozesszeiten bei, verschieben aber die betroffene Lieferantengruppe systematisch nach oben.
Das ist für spätere Process-Mining-Analysen deutlich sinnvoller, als allen Globex-Fällen einen identischen festen Zeitwert zu geben.
Unterschied zu Maverick Buying
Die ersten beiden Use Cases zeigen zwei grundsätzlich verschiedene Arten kausaler Modellierung.
Beim Maverick Buying beeinflusst ein Attribut: anforderer die Frage:
Welcher Prozesspfad wird tatsächlich durchlaufen?
Bei der Lieferantenperformance beeinflusst ein Attribut: lieferant dagegen:
Wie lange dauert der Prozess?
Die Prozessstruktur selbst bleibt erhalten.
Damit können wir unterschiedliche Arten von Ursachen synthetisch erzeugen und später getrennt analysieren.
Was sollte ich später in Noreja sehen?
Bei einer Analyse der Durchlaufzeiten sollten Bestellungen mit:
Globex SE
im Durchschnitt längere Zeiten aufweisen als vergleichbare Bestellungen anderer Lieferanten.
Interessante Fragestellungen sind beispielsweise:
Welche Lieferanten besitzen die höchsten durchschnittlichen Durchlaufzeiten?
Ist Globex SE überproportional in langsam laufenden Cases vertreten?
An welcher Stelle im Prozess entsteht die zusätzliche Wartezeit?
Der interessante Teil ist dabei nicht, dass Globex einfach mit einem Label als „schlecht“ markiert wurde.
Die schlechtere Performance wird über das tatsächliche Zeitverhalten des Prozesses erzeugt.
Typische Fehler / darauf achten
Die Regel verändert den Gap nach der ausgewählten Aktivität.
Wer eine Verzögerung an einer bestimmten Stelle erzeugen möchte, muss deshalb immer prüfen, welcher Slot den entsprechenden Übergang steuert.
Faktor 3 bedeutet nicht „plus drei Tage“.× factor = 3 multipliziert den vorhandenen Zeitabstand. Für einen festen Aufschlag würde stattdessen + days verwendet.
Reference Data und Prozessobjekt unterscheiden.lieferant liegt nicht selbst in der Causal Chain. Über lieferant_id kann die Bestellung trotzdem dessen Attribute als Ursache verwenden.
Ergebnis
Wir haben nun einen zweiten kausalen Zusammenhang im Datensatz:
lieferant = Globex SE
→ längerer Zeitabstand
→ höhere Prozessdurchlaufzeit.
Damit enthält unser Datensatz inzwischen sowohl eine strukturelle Abweichung durch Maverick Buying als auch eine Performance-Abweichung durch längere Prozesszeiten.
Nächster Schritt
Als Nächstes modellieren wir ein Muster, bei dem ein bereits durchgeführter Prozessschritt nochmals bearbeitet werden muss:
Bestelländerung / Rework
Dafür verwenden wir erstmals das Rework-Behaviour und erzeugen die Abweichung mit einer festen Quote von 15 %.