---
title: "Tutorial P2P - Fehlermuster schlechte Lieferperformance"
url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-schlechte-lieferperformance"
language: "de"
last_updated: "2026-09-22T08:54:37.180Z"
---

# 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 mit `Globex SE` erhalten 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.

![](https://cdn-assets.productfruits.com/9d86b015-c157-4270-8f7d-3c37c8112af1)

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

![](https://cdn-assets.productfruits.com/570b1915-5f18-4add-b0b1-6c6043dd98e4)

Damit lautet die Bedingung fachlich:

> Wenn die Bestellung zum Lieferanten `Globex SE` gehö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 %**.

**Weiter:**  [**Tutorial P2P Fehlermuster Bestelländerung (Rework)**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-fehlermuster-bestellanderung-rework)