P2P Expert - Kapazitätsengpass
TL;DR
Ziel: Eine begrenzte Prüfkapazität erzeugen, sodass nicht alle Wareneingänge sofort geprüft werden können.
Voraussetzungen: Der physische Beschaffungspfad mitwareneingang_pruefungist vorhanden undMode: Expertist 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.