---
title: "Tutorial P2P - Fehlermuster Prozessabbruch"
url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-prozessabbruch"
language: "de"
last_updated: "2026-09-22T08:57:42.075Z"
---

# 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.

![](https://cdn-assets.productfruits.com/8bd40286-dd2f-4a07-858d-6122a77ee541)

## 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.

![](https://cdn-assets.productfruits.com/cea4c8b8-4112-4c46-bcad-c58ee820f28a)

## 2\. Weitere Abbruchpunkte konfigurieren

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

| Prozess endet nach | Wahrscheinlichkeit | Tag |
| --- | --- | --- |
| `bestellanforderung` | 8 % | `PROZESS_OFFEN_NACH_BESTELLANFORDERUNG` |
| `bestellung` | 6 % | `PROZESS_OFFEN_NACH_BESTELLUNG` |
| `bestellposition` | 5 % | `PROZESS_OFFEN_NACH_BESTELLPOSITION` |
| `rechnung` | 3 % | `PROZESS_OFFEN_NACH_RECHNUNG` |
| `rechnung_freigabe` | 2 % | `PROZESS_OFFEN_NACH_RECHNUNGSFREIGABE` |

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

Damit entstehen reproduzierbare Abbruchquoten.

![](https://cdn-assets.productfruits.com/dd69a0c6-d70e-4744-a803-01dc1a365e99)

## 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**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-skontoverlust-working-capital)