--- title: "Tutorial P2P Expert - Kapazitätsengpass" url: "https://docs.noreja.com/de/article/noreja-smart-data-forge-p2p-expert-kapazitatsengpass" language: "de" last_updated: "2026-09-22T10:42:38.791Z" --- # Tutorial P2P Expert - Kapazitätsengpass Von einer normalen Wareneingangsprüfung zu einer begrenzten Ressource mit Warteschlange. > **TL;DR** > **Ziel:** Eine begrenzte Prüfkapazität erzeugen, sodass nicht alle Wareneingänge sofort geprüft werden können. > **Voraussetzungen:** Der physische Beschaffungspfad mit `wareneingang_pruefung` ist vorhanden und `Mode: Expert` ist aktiv. > **Ergebnis:** Wareneingänge werden nur dienstags und donnerstags geprüft. Reicht die Kapazität eines Termins nicht aus, wandern überzählige Prüfungen in den nächsten Termin und bilden einen Backlog. ## Fachliche Fragestellung Ein Prozess kann auch dann langsam werden, wenn alle einzelnen Aktivitäten korrekt funktionieren. Ein typisches Beispiel ist eine Ressource mit begrenzter Kapazität. In unserem P2P-Prozess werden physische Lieferungen nach dem Wareneingang geprüft. Die fachliche Frage lautet: **Was passiert, wenn mehr Wareneingänge zur Prüfung anstehen, als die vorhandenen Prüfplätze bearbeiten können?** Dann entsteht keine zufällige Verzögerung, sondern eine kausale Warteschlange: `Wareneingang` → begrenzte Prüfkapazität → Backlog → spätere Wareneingangsprüfung. ## Gewünschtes Datenbild Ohne Kapazitätsengpass könnte jeder Wareneingang unabhängig von der aktuellen Auslastung geprüft werden. Mit Capacity Bottleneck gibt es dagegen feste Prüfungstermine: **Dienstag, 08:00 Uhr** und **Donnerstag, 08:00 Uhr** Jeder neue Wareneingang wird zunächst dem nächsten möglichen Prüfungstermin zugeordnet. Ist dort noch Kapazität vorhanden, findet die Prüfung wie geplant statt. Ist der Termin bereits voll, rutscht der Vorgang in den nächsten Prüfungstermin. Beispiel: `Wareneingang Montag` → geplant: Dienstag 08:00 → Dienstag bereits ausgelastet → tatsächliche Prüfung: Donnerstag 08:00 Genau diese Differenz wollen wir später im Datensatz sichtbar machen. ## 1\. Capacity Bottleneck öffnen Wechsle zu: `07 Capacity Bottleneck` Dieser Bereich ist nur im: `Mode: Expert` sichtbar. Hier definieren wir nicht mehr nur einen normalen zeitlichen Abstand zwischen zwei Aktivitäten, sondern eine tatsächliche **Bearbeitungsressource mit begrenzter Kapazität**. ## 2\. Zu prüfende Aktivität auswählen Als Activity verwenden wir: `wareneingang_pruefung` Die Tabelle enthält bereits die notwendigen Felder für den Bottleneck: `pruefung_geplant_am` `wareneingang_geprueft_am` `verzoegerung_slots` `pruefkapazitaet_ueberschritten` `pruefplatz` \[SCREENSHOT: Capacity Bottleneck mit wareneingang\_pruefung als Activity\] ## 3\. Ankunft der Arbeit definieren Die Prüfung soll beginnen können, sobald ein Wareneingang gebucht wurde. Deshalb konfigurieren wir: **Activity table:** `wareneingang_pruefung` **Arrival via FK:** `wareneingang_id` **Arrival timestamp:** `wareneingang_gebucht_am` Damit kennt die Smart Data Forge für jede Prüfung den Zeitpunkt, ab dem sie in der Warteschlange verfügbar ist. Die Zuordnung erfolgt über den Foreign Key von `wareneingang_pruefung` auf `wareneingang`. Fachlich: `wareneingang_gebucht_am` → Vorgang wartet ab diesem Zeitpunkt auf einen freien Prüfplatz. ## 4\. Ergebnisfelder zuordnen Als tatsächlich ausgeführten Prüfzeitpunkt verwenden wir: **Processed at:** `wareneingang_geprueft_am` Zusätzlich speichern wir den ursprünglich vorgesehenen Termin in: **Planned appointment:** `pruefung_geplant_am` Die beiden Werte ermöglichen später einen direkten Vergleich: `pruefung_geplant_am` gegen `wareneingang_geprueft_am` Wenn beide identisch sind, gab es keinen Backlog. Liegt die tatsächliche Prüfung später, musste der Vorgang auf einen späteren Prüfungstermin warten. Zusätzlich verwenden wir: **Delay in appointments:** `verzoegerung_slots` **Overflow flag:** `pruefkapazitaet_ueberschritten` **Role/group column:** `pruefplatz` Die Engine schreibt in `verzoegerung_slots`, um wie viele Prüfungstermine der Vorgang verschoben wurde. `pruefkapazitaet_ueberschritten` wird auf `1` gesetzt, sobald tatsächlicher und ursprünglich vorgesehener Prüfungstermin auseinanderfallen. \[SCREENSHOT: Mapping der Capacity-Ergebnisfelder\] ## 5\. Prüfungstermine definieren Unter: `2. When is it processed?` aktivieren wir: `Tue` und `Thu` Als: `Time of day (hour)` setzen wir: `8` Damit entstehen zwei feste Bearbeitungsfenster pro Woche: **Dienstag um 08:00 Uhr** **Donnerstag um 08:00 Uhr** Diese Einstellung entspricht der bestehenden P2P-Expert-Konfiguration. \[SCREENSHOT: Tuesday und Thursday, Time of day 8\] ## Wie wird der geplante Termin bestimmt? Für jeden Wareneingang sucht die Capacity-Logik den **ersten Prüfungstermin, der zeitlich nach der Ankunft liegt**. Beispiel: Wareneingang: `Montag 15:00` nächster Termin: `Dienstag 08:00` Damit wird zunächst: `pruefung_geplant_am = Dienstag 08:00` gesetzt. Ein Wareneingang von: `Dienstag 10:00` hat diesen Termin bereits verpasst. Der nächste mögliche Termin ist deshalb: `Donnerstag 08:00`. Die Forge berechnet diesen natürlichen beziehungsweise geplanten Termin zunächst unabhängig von der vorhandenen Kapazität. ## 6\. Kapazität über Prüfplätze definieren Unter: `3. How much fits into one appointment?` wähle bei: `Set capacity via` die Option: `Capacity per role/group` Wir verwenden zwei Prüfplätze: | Prüfplatz | Kapazität pro Termin | | --- | --- | | `Prüfplatz 1` | 8 | | `Prüfplatz 2` | 8 | Damit können pro Prüfungstermin insgesamt: **16 Prüfungen** bearbeitet werden. Die vollständige P2P-Konfiguration verwendet genau diese beiden Prüfplätze mit jeweils einer Kapazität von 8. \[SCREENSHOT: Prüfplatz 1 und Prüfplatz 2 mit Capacity 8\] ## Kapazität pro Case Als: `Unit` verwenden wir: `Cases (count)` Damit benötigt jede Wareneingangsprüfung genau eine Kapazitätseinheit. Ein Prüfungstermin mit einer Gesamtkapazität von 16 kann somit maximal 16 Prüfungen aufnehmen. ## 7\. Backlog aktivieren Aktiviere: `Backlog` Jetzt wird aus begrenzter Kapazität tatsächlich eine Warteschlange. Angenommen, für Dienstag liegen: `20 Prüfungen` vor. Die vorhandene Kapazität beträgt: `16` Dann werden: `16 Prüfungen` am Dienstag bearbeitet. Die verbleibenden: `4 Prüfungen` rutschen zum nächsten verfügbaren Termin: `Donnerstag 08:00` Die Engine arbeitet dabei die wartenden Vorgänge anhand ihrer Ankunftsreihenfolge ab und verschiebt nicht mehr passende Vorgänge in spätere Termine. \[SCREENSHOT: Backlog aktiviert\] ## Was wird im Datensatz sichtbar? Ein Vorgang ohne Engpass kann beispielsweise so aussehen: `pruefung_geplant_am = Dienstag 08:00` `wareneingang_geprueft_am = Dienstag 08:00` `verzoegerung_slots = 0` `pruefkapazitaet_ueberschritten = 0` Ein Vorgang mit Backlog dagegen: `pruefung_geplant_am = Dienstag 08:00` `wareneingang_geprueft_am = Donnerstag 08:00` `verzoegerung_slots = 1` `pruefkapazitaet_ueberschritten = 1` Wird auch der Donnerstag vollständig ausgelastet, kann ein Vorgang entsprechend noch weiter nach hinten verschoben werden. Dadurch entsteht kein künstlicher fixer Delay, sondern eine Verzögerung aus dem tatsächlichen Verhältnis von: **Arbeitsaufkommen** und **verfügbarer Kapazität**. ## Zuordnung zum Prüfplatz Die bearbeiteten Prüfungen werden zusätzlich einem der konfigurierten Prüfplätze zugeordnet: `Prüfplatz 1` oder `Prüfplatz 2` Der Wert wird in: `pruefplatz` gespeichert. Damit kann später beispielsweise untersucht werden: **Wie stark sind die einzelnen Prüfplätze ausgelastet?** oder: **Welche Vorgänge mussten aufgrund des Engpasses auf einen späteren Termin warten?** ## Optionales Prüfbatch-Objekt Die vollständige Expert-Konfiguration kann zusätzlich ein eigenes Objekt: `pruefbatch` erzeugen. Dabei erhalten Prüfungen, die am gleichen Termin und am gleichen Prüfplatz bearbeitet wurden, ein gemeinsames Batch-Objekt. Für das Verständnis des Capacity Bottlenecks ist dieses zusätzliche Objekt nicht zwingend notwendig. Der zentrale Zusammenhang bleibt: `Wareneingang` → nächster möglicher Prüfungstermin → begrenzte Kapazität → eventuell Backlog → tatsächlicher späterer Prüftermin. ## Capacity Bottleneck SQL erzeugen Die Capacity-Konfiguration verändert die bereits generierten Daten nicht direkt im Browser. Stattdessen erzeugt `07 Capacity Bottleneck` ein zusätzliches SQL-Skript. Die vorgesehene Reihenfolge lautet deshalb: `data.sql` → zuerst auf SQL Server ausführen danach: `Capacity Bottleneck SQL` → auf denselben Daten ausführen. Das generierte Capacity-Skript ist ausdrücklich dafür vorgesehen, **nach dem normalen Data-SQL** ausgeführt zu werden. \[SCREENSHOT: generiertes Capacity Bottleneck SQL\] ## Was sollte ich später in Noreja sehen? Im Process Mining sollten nun Fälle mit deutlich unterschiedlichen Wartezeiten vor der Wareneingangsprüfung sichtbar werden. Interessant sind insbesondere Zusammenhänge zwischen: `wareneingang_gebucht_am` `pruefung_geplant_am` `wareneingang_geprueft_am` und: `verzoegerung_slots`. Damit lassen sich beispielsweise Fragen untersuchen wie: **Wie viele Prüfungen konnten nicht zum ersten möglichen Termin durchgeführt werden?** **Wie groß ist der durchschnittliche Backlog?** **An welchen Prüfungsterminen entsteht besonders häufig eine Kapazitätsüberschreitung?** **Wie stark beeinflusst der Engpass die Durchlaufzeit des physischen Beschaffungspfads?** Anders als bei unserer früheren Lieferantenregel entsteht die Verzögerung hier nicht durch einen direkt eingestellten Zeitfaktor. Sie entsteht aus dem Zusammenspiel von **Ankunftszeit, festen Bearbeitungsterminen und begrenzter Kapazität**. ## Typische Fehler / darauf achten **Backlog aktivieren.** Ohne Backlog entsteht keine echte Warteschlange über mehrere Prüfungstermine. **Geplanten und tatsächlichen Termin getrennt speichern.** Nur so kann später nachvollzogen werden, ob eine Prüfung verschoben wurde. **Capacity per role/group richtig interpretieren.** Bei zwei Prüfplätzen mit jeweils 8 beträgt die wirksame Gesamtkapazität 16 Prüfungen pro Termin. **Capacity SQL nach** `**data.sql**` **ausführen.** Der Bottleneck wird als nachgelagerte SQL-Transformation auf den bereits erzeugten Daten angewendet. ## Ergebnis Wir haben nun erstmals einen echten ressourcengetriebenen Bottleneck modelliert: `Wareneingänge treffen ein` → Prüfungen sind nur Dienstag und Donnerstag möglich → pro Termin stehen 16 Plätze zur Verfügung → Kapazität wird überschritten → Vorgänge wandern in den nächsten Termin → Backlog entsteht. Damit besitzt unser synthetischer Prozess eine Verzögerung, die nicht einfach vorgegeben wird, sondern **aus einer realistischen Kapazitätsrestriktion entsteht**. ## Nächster Schritt Bisher wirkt sich der Bottleneck nur unmittelbar auf: `wareneingang_pruefung` aus. Im nächsten Expert-Use-Case stellen wir die entscheidende kausale Frage: **Was passiert mit dem restlichen Prozess, wenn sich die Wareneingangsprüfung verzögert?** Dafür aktivieren wir die: **Delay Propagation** und übertragen die entstandene Verzögerung auf Rechnung und Zahlung. **Weiter:** [**Tutorial P2P -  Verzögerung und Skontoverlust**](https://docs.noreja.com/de/article/noreja-smart-data-forge-tutorial-p2p-expert-verzogerung-und-skontoverlust)