Tutorial P2P Expert - Bündelung und Freigabelauf

TL;DR
Ziel: Mehrere Rechnungen in regelmäßigen gemeinsamen Freigabeläufen bündeln.
Voraussetzungen: Das Expert-P2P-Modell ist aufgebaut und die Rechnungen enthalten freigabelauf_id.
Ergebnis: Alle bis zu einem Lauf fälligen Rechnungen werden dem nächsten wöchentlichen Freigabelauf am Freitag um 09:00 Uhr zugeordnet.

Fachliche Fragestellung

Nicht jede Aktivität wird unmittelbar ausgeführt, sobald ein einzelnes Objekt bereitsteht.

In vielen Unternehmen werden beispielsweise Rechnungen gesammelt und anschließend in einem regelmäßigen Lauf gemeinsam verarbeitet.

Die fachliche Frage lautet:

Wie verändert sich das Prozessbild, wenn Rechnungen nicht unabhängig voneinander, sondern gesammelt in periodischen Freigabeläufen bearbeitet werden?

Für dieses Szenario verwenden wir:

08 Bundling

Gewünschtes Datenbild

Ohne Bundling werden Rechnungen als einzelne Objekte betrachtet:

Rechnung A

Rechnung B

Rechnung C

Mit Bundling sollen mehrere Rechnungen einem gemeinsamen Lauf zugeordnet werden:

Rechnung A ─┐

Rechnung B ─┼→ Freigabelauf Freitag 09:00

Rechnung C ─┘

Der Freigabelauf wird dadurch selbst zu einem Business Object.

Mehrere Rechnungen referenzieren denselben:

freigabelauf_id

Damit entsteht eine echte N:1-Beziehung.

1. Bundling öffnen

Wechsle zu: 08 Bundling

und aktiviere: Generate collection run

Die Smart Data Forge beschreibt Bundling als periodischen Sammellauf: Alle bis zu einem Termin fälligen Objekte werden gemeinsam einem Lauf zugeordnet. Anders als beim Capacity Bottleneck gibt es dabei keine begrenzte Slot-Kapazität.

Das bedeutet:

Capacity Bottleneck

→ Ein Termin kann voll werden.
→ Überzählige Objekte müssen warten.

Bundling

→ Alle fälligen Objekte werden aufgenommen.
→ Niemand wartet aufgrund einer Kapazitätsgrenze.

2. Rechnungen als zu sammelnde Objekte auswählen

Setze:

Which objects are collected? rechnung

When does an object become due?  rechnung_freigegeben_am

Damit gilt eine Rechnung ab ihrer Freigabe als bereit für den nächsten Sammellauf.

Die vorbereitete P2P-Expert-Konfiguration verwendet genau diese Kombination.

Wie wird eine Rechnung einem Lauf zugeordnet?

Die Bundling-Logik sucht für jede Rechnung den ersten Lauf, dessen Zeitpunkt gleich oder später als rechnung_freigegeben_am liegt.

Beispiel:

Eine Rechnung wird freigegeben: Mittwoch 14:00

Der nächste Lauf findet statt: Freitag 09:00

Die Rechnung wird deshalb diesem Freitagslauf zugeordnet. 

Eine Rechnung wird dagegen erst: Freitag 11:00 freigegeben. 

Der Lauf um 09:00 Uhr ist bereits vorbei.

Sie landet deshalb im: Freigabelauf der folgenden Woche.

3. Neues Collection Object erzeugen

Bei:

Target table: wähle: Create new table

Collection object table: freigabelauf

Execution timestamp (on the collection object): freigabe_am

Role/group column (optional): rolle

Die Tabelle muss vorher nicht unter Define Tables angelegt werden.

Beim Ausführen des erzeugten Bundling-SQL wird sie automatisch erstellt.

Was enthält freigabelauf?

Bei unserem Szenario erzeugt das SQL eine Tabelle mit Informationen wie:

freigabelauf_id

freigabe_am

rolle

anzahl

Dabei steht anzahl für die Anzahl der Rechnungen, die diesem Lauf zugeordnet wurden.

Beispiel:

Dadurch kann später nicht nur die einzelne Rechnung, sondern auch der Sammellauf selbst analysiert werden.

4. Rechnungen mit dem Freigabelauf verbinden

Link on the business object (FK): freigabelauf_id

Nach der Generierung schreibt das Bundling-SQL die ID des zugewiesenen Laufs zurück in die jeweilige Rechnung.

Dadurch entsteht:

rechnung.freigabelauf_id

→ freigabelauf.freigabelauf_id

Mehrere Rechnungen können auf denselben Freigabelauf zeigen.

Genau dadurch entsteht die gewünschte N:1-Struktur.

5. Wöchentlichen Lauf konfigurieren

Run hour: 9

Frequency: weekly

Weekday: friday

jeden Freitag um 09:00 Uhr.

6. Rolle hinterlegen

Roles/groups (round-robin per run) : Kreditoren

Damit erhält der erzeugte Freigabelauf:

rolle = Kreditoren

Die Engine unterstützt mehrere Rollen und würde diese pro Lauf im Round-Robin-Verfahren verteilen. Für unser P2P-Beispiel verwenden wir jedoch bewusst nur eine Rolle.

Die fertige Konfiguration

Capacity Bottleneck vs. Bundling

Die beiden Expert-Funktionen sehen auf den ersten Blick ähnlich aus, modellieren aber unterschiedliche fachliche Situationen.

Capacity Bottleneck

Es gibt feste Termine und begrenzte Kapazität.

Beispiel:

20 Prüfungen warten

→ Kapazität 16

→ 4 Prüfungen wandern in den nächsten Termin.

Der entscheidende Mechanismus ist:

Ressourcenknappheit.

Bundling

Es gibt ebenfalls feste Termine, aber keine Kapazitätsgrenze.

Beispiel:

20 Rechnungen warten

→ Freitag 09:00

→ alle 20 Rechnungen werden im Lauf verarbeitet.

Der entscheidende Mechanismus ist:

bewusstes Sammeln bis zu einem periodischen Termin.

Damit erzeugen Capacity und Bundling zwar beide zeitliche Häufungen, aber aus völlig unterschiedlichen Ursachen.

Was verändert Bundling an der Rechnung?

Bundling erzeugt nicht einfach zufällig einen neuen Timestamp auf jeder Rechnung.

Stattdessen erzeugen wir ein separates Business Object: freigabelauf

und verknüpfen die Rechnung über: freigabelauf_id mit diesem Objekt.

Der Lauf besitzt seinen eigenen: freigabe_am Timestamp.

Damit können mehrere Rechnungen exakt denselben Lauf referenzieren.

Das ist insbesondere für Causal Process Mining interessant, weil der Sammellauf als eigenständiges Objekt erhalten bleibt.

Bundling SQL erzeugen

Klicke: Generate bundling SQL

Das Bundling wird – genau wie die Capacity-Logik – als separates SQL-Skript erzeugt.

Reihenfolge der SQL-Skripte im Expert-Szenario

Für unser vollständiges Expert-Szenario verwenden wir folgende Reihenfolge:

data.sql

→ erzeugt die eigentlichen P2P-Daten

capacity.sql

→ erzeugt Prüfplatz-Backlog, Delay Propagation und Skontoverlust

bundling.sql

→ ordnet die anschließend vorhandenen Rechnungen den Freigabeläufen zu.

Diese Reihenfolge ist für unser Szenario sinnvoll, weil das Capacity-SQL rechnung_freigegeben_am verändern kann. Das Bundling sollte anschließend mit den bereits aktualisierten Rechnungszeitpunkten arbeiten.

Was sollte ich später in Noreja sehen?

In Noreja sollten mehrere Rechnungen auf denselben:

freigabelauf

zulaufen.

Typische Muster sind:

Rechnung A ─┐

Rechnung B ─┼→ Freigabelauf

Rechnung C ─┘

Damit lassen sich beispielsweise folgende Fragen analysieren:

Wie viele Rechnungen werden durchschnittlich pro Freigabelauf verarbeitet?

Wie lange wartet eine Rechnung zwischen ihrer Freigabe und dem nächsten Freigabelauf?

Welche Wochentage beziehungsweise Laufzeiten erzeugen systematisch Wartezeit?

Wie stark schwankt das Volumen der einzelnen Freigabeläufe?

Welche Rechnungen verpassen einen Lauf knapp und müssen fast eine ganze Woche warten?

Gerade der letzte Fall zeigt eine typische Bundling-Wirkung:

Eine Rechnung am:

Freitag 08:55

kann noch dem Lauf um:

09:00

zugeordnet werden.

Eine Rechnung am:

Freitag 09:05

muss dagegen bis zum nächsten wöchentlichen Lauf warten.

Typische Fehler / darauf achten

Bundling nicht mit Capacity verwechseln.
Beim Freigabelauf gibt es keine Kapazitätsgrenze. Alle fälligen Rechnungen werden aufgenommen.

Den richtigen Due-Timestamp verwenden.
Für unser Beispiel ist das rechnung_freigegeben_am.

freigabelauf_id als Link setzen.
Nur dadurch entsteht die relationale Verbindung zwischen Rechnung und Sammellauf.

SQL-Reihenfolge beachten.
Im vollständigen Expert-Szenario sollte bundling.sql nach dem Capacity-SQL ausgeführt werden, damit bereits propagierte Rechnungszeiten berücksichtigt werden.

Ergebnis

Unser Expert-Datensatz enthält nun zwei unterschiedliche Arten gemeinsamer Bearbeitung:

Capacity Bottleneck

→ mehrere Objekte konkurrieren um eine begrenzte Ressource.

Bundling

→ mehrere Objekte werden bewusst bis zu einem gemeinsamen Verarbeitungstermin gesammelt.

Der Freigabelauf wird dabei selbst zu einem Business Object und verbindet mehrere Rechnungen über eine echte N:1-Beziehung.

Damit ist der Expert-Teil des Demo-Trainings abgeschlossen.

Abschluss des Expert-Modells

Speichere den aktuellen Stand als:

Config 3 – Expert

Das Expert-Modell enthält nun zusätzlich zum Simple-Modell:

PHYSICAL- und SOFTWARE-Beschaffungspfade

Wareneingangsprüfung

Capacity Bottleneck

Backlog

Delay Propagation

berechneten Skontoverlust

Bundling mit wöchentlichen Freigabeläufen

Damit steht das vollständige Trainingsmodell für die anschließende Analyse in Noreja bereit.