Tutorial P2P - Fehlermuster Prozessabbruch

TL;DR
Ziel: Prozesse erzeugen, die an unterschiedlichen Stellen enden und dadurch offen bleiben.
Voraussetzungen: Die bisherigen Simple-Use-Cases sind konfiguriert.
Ergebnis: Ein Teil der Cases endet gezielt nach Bestellanforderung, Bestellung, Bestellposition, Rechnung oder Rechnungsfreigabe.

Fachliche Fragestellung

Nicht jeder Beschaffungsprozess wird vollständig abgeschlossen.

Typische Fragestellungen sind:

Wo brechen Prozesse besonders häufig ab?

Welche Bestellungen erreichen nie einen Wareneingang oder eine Rechnung?

Welche Rechnungen werden freigegeben, aber anschließend nicht bezahlt?

Wie ist der aktuelle Zustand meines Prozesses.

Für solche Fälle verwenden wir das Abort-Behaviour.

Gewünschtes Datenbild

Ein normaler Case durchläuft beispielsweise:

Bestellanforderung

→ Bestellung

→ Bestellposition

→ Wareneingang

→ Rechnung

→ Rechnungsfreigabe

→ Zahlung

Ein offener Case kann dagegen beispielsweise bereits hier enden:

Bestellanforderung

→ Bestellung

→ Bestellposition

→ Ende

Der letzte Prozessschritt ist vorhanden, alle nachfolgenden Prozessobjekte fehlen.

Was macht Abort?

Öffne: 04 Special Behaviour

und wähle: Abort (stop process after this slot)

Bei einem Abort wird der ausgewählte Slot selbst noch erzeugt.

Alle nachfolgenden Prozessschritte werden dagegen nicht mehr erzeugt.

Beispiel:

Slot to stop after:
bestellung

Ergebnis:

Bestellanforderung → Bestellung → Ende

Es entstehen für diesen Case keine nachgelagerten Bestellpositionen, Wareneingänge, Rechnungen oder Zahlungen.

Abort ist nicht dasselbe wie Drop-off

Bei Status-Spalten gibt es zusätzlich die Einstellung:

Drop-off %

Diese beendet jedoch nur die interne Statusfolge der jeweiligen Tabelle. Sie garantiert nicht, dass auch die gesamte nachgelagerte Causal Chain endet.

Für echte offene Prozesse verwenden wir deshalb:

Abort

1. Offene Prozesse nach der Bestellanforderung

Lege eine neue Regel an:

Type:
Abort

Slot to stop after:
bestellanforderung

Probability (%):
8

exactly N % (fixed rate):
aktiviert

Tag:
PROZESS_OFFEN_NACH_BESTELLANFORDERUNG

Damit werden bei 500 Cases für diese Regel:  40 Cases ausgewählt.

2. Weitere Abbruchpunkte konfigurieren

Im Simple-P2P-Modell verwenden wir mehrere Abbruchpunkte aus der bestehenden Demo-Konfiguration.

Für jede Regel aktivieren wir: exactly N % (fixed rate)

Damit entstehen reproduzierbare Abbruchquoten.

Was bedeuten die einzelnen Abbruchpunkte?

Nach bestellanforderung

Es wurde ein Bedarf angelegt, aber keine Bestellung erstellt.

Bestellanforderung → Ende

Nach bestellung

Eine Bestellung existiert, wird aber nicht weiter verarbeitet.

Bestellanforderung → Bestellung → Ende

Nach bestellposition

Die Bestellung enthält Positionen, erreicht aber keinen Wareneingang.

... → Bestellposition → Ende

Nach rechnung

Eine Rechnung wurde erfasst, aber nicht freigegeben.

... → Rechnung → Ende

Nach rechnung_freigabe

Die Rechnung wurde freigegeben, aber es entsteht keine Zahlung.

... → Rechnungsfreigabe → Ende

Gerade der letzte Fall ist später für Working-Capital- und Zahlungsanalysen interessant.

Wichtig: Die Regeln können sich überschneiden

Jede Abort-Regel wählt bei aktivem exactly N % ihre Cases separat aus. Die Engine bestimmt dafür pro Regel exakt round(Probability × Number of cases) Case-Indizes.

Ein Case kann dadurch theoretisch von mehreren Abort-Regeln ausgewählt werden.

Wenn ein Case beispielsweise sowohl für:

Abort nach bestellung

als auch für:

Abort nach rechnung

ausgewählt wurde, endet er bereits nach der Bestellung.

Der früheste Abbruchpunkt bestimmt also den tatsächlich sichtbaren Prozessendpunkt.

Die Prozentwerte sollten deshalb als konfigurierte Quote je Regel verstanden werden und nicht einfach zu einer Gesamt-Abbruchquote addiert werden.

Was sollte ich später in Noreja sehen?

Im Process Mining sollten nun mehrere unvollständige kausale Varianten entstehen.

Beispiele:

Bestellanforderung → Ende

Bestellanforderung → Bestellung → Ende

... → Rechnung → Ende

... → Rechnungsfreigabe → Ende

Daraus ergeben sich typische Fragestellungen wie:

An welcher Stelle enden Prozesse besonders häufig?

Welche Attribute unterscheiden vollständige von offenen Cases?

Welche Lieferanten, Produktgruppen oder Anforderer treten bei offenen Prozessen häufiger auf?

Wie viel Bestellvolumen steckt in noch nicht abgeschlossenen Vorgängen?

Unterschied zu den bisherigen Use Cases

Maverick Buying
→ ein vorgesehener Freigabeschritt wird umgangen.

Lieferantenperformance
→ der Prozess wird langsamer.

Rework
→ ein Objekt wird erneut bearbeitet.

Wrong Order
→ Aktivitäten liegen in der falschen zeitlichen Reihenfolge.

Abort
→ der Prozess endet vollständig oder pausiert an einem definierten Punkt.

Damit haben wir nun auch unvollständige Cases im synthetischen Datensatz.

Typische Fehler / darauf achten

Den Slot auswählen, der noch stattfinden soll.
Abort after bestellung bedeutet: Die Bestellung wird noch erzeugt – erst danach endet der Prozess.

Abort nicht mit Drop-off % verwechseln.
Abort beendet die nachgelagerte Causal Chain.

Prozentwerte nicht einfach addieren.
Mehrere Abort-Regeln können denselben Case auswählen.

exactly N % aktivieren.
So bleiben die konfigurierten Quoten über wiederholte Trainingsläufe reproduzierbar.

Ergebnis

Unser P2P-Datensatz enthält nun neben vollständigen Prozessen auch gezielt offene Cases mit unterschiedlichen Endpunkten.

Dadurch können wir später nicht nur Prozessvarianten und Durchlaufzeiten analysieren, sondern auch untersuchen:

Warum werden bestimmte Beschaffungsprozesse nicht abgeschlossen?

Nächster Schritt

Als letzten Simple-Use-Case verbinden wir Prozesszeit mit einem finanziellen Effekt:

Skontoverlust und Working Capital

Dafür verzögern wir Zahlungen gezielt und untersuchen, wann dadurch vorhandene Skontofristen überschritten werden.

Weiter: Tutorial P2P Skontoverlust - Working Capital