Tutorial P2P Expert - Capacity Bottleneck

TL;DR 
Goal: Generate a limited inspection capacity so that not all goods receipts can be inspected immediately. 
Prerequisites: The physical procurement path with wareneingang_pruefung is in place and Mode: Expert is active. 
Result: Goods receipts are inspected only on Tuesdays and Thursdays. If the capacity of one appointment is not enough, surplus inspections move to the next appointment and form a backlog.

The business question

A process can also become slow when all the individual activities function correctly.

A typical example is a resource with limited capacity.

In our P2P process, physical deliveries are inspected after the goods receipt.

The business question is:

What happens when more goods receipts are queued for inspection than the available inspection stations can process?

Then no random delay arises, but a causal queue:

Wareneingang

→ limited inspection capacity

→ backlog

→ later goods-receipt inspection.

Desired data picture

Without a capacity bottleneck, every goods receipt could be inspected independently of the current workload.

With a capacity bottleneck, by contrast, there are fixed inspection appointments:

Tuesday, 08:00

and

Thursday, 08:00

Each new goods receipt is first assigned to the next possible inspection appointment.

If capacity is still available there, the inspection takes place as planned.

If the appointment is already full, the transaction slips to the next inspection appointment.

Example:

Wareneingang Montag

→ planned: Tuesday 08:00

→ Tuesday already at capacity

→ actual inspection: Thursday 08:00

It is precisely this difference that we want to make visible in the data set later.

1. Opening Capacity Bottleneck

Switch to: 07 Capacity Bottleneck

This area is only visible in: Mode: Expert

Here we no longer define merely a normal temporal gap between two activities, but an actual processing resource with limited capacity.

2. Selecting the activity to be inspected

As the activity we use: wareneingang_pruefung

The table already contains the necessary fields for the bottleneck:

pruefung_geplant_am

wareneingang_geprueft_am

verzoegerung_slots

pruefkapazitaet_ueberschritten

pruefplatz

[SCREENSHOT: Capacity Bottleneck with wareneingang_pruefung as the activity]

3. Defining the arrival of the work

The inspection should be able to begin as soon as a goods receipt has been recorded.

We therefore configure:

Activity table: 
wareneingang_pruefung

Arrival via FK: 
wareneingang_id

Arrival timestamp: 
wareneingang_gebucht_am

This way the Smart Data Forge knows, for each inspection, the point in time from which it is available in the queue. The assignment is made via the foreign key from wareneingang_pruefung to wareneingang.

In business terms:

wareneingang_gebucht_am

→ the transaction waits from this point in time for a free inspection station.

4. Mapping the result fields

As the actually executed inspection time we use:

Processed at: 
wareneingang_geprueft_am

Additionally, we store the originally intended appointment in:

Planned appointment: 
pruefung_geplant_am

The two values later enable a direct comparison:

pruefung_geplant_am

against

wareneingang_geprueft_am

If both are identical, there was no backlog.

If the actual inspection is later, the transaction had to wait for a later inspection appointment.

Additionally, we use:

Delay in appointments: 
verzoegerung_slots

Overflow flag: 
pruefkapazitaet_ueberschritten

Role/group column: 
pruefplatz

The engine writes into verzoegerung_slots by how many inspection appointments the transaction was postponed. pruefkapazitaet_ueberschritten is set to 1 as soon as the actual and originally intended inspection appointment diverge.

[SCREENSHOT: Mapping of the capacity result fields]

5. Defining the inspection appointments

Under:

2. When is it processed?

we enable:

Tue

and

Thu

As:

Time of day (hour)

we set:

8

This creates two fixed processing windows per week:

Tuesday at 08:00

Thursday at 08:00

This setting corresponds to the existing P2P Expert configuration.

[SCREENSHOT: Tuesday and Thursday, Time of day 8]

How is the planned appointment determined?

For each goods receipt, the capacity logic looks for the first inspection appointment that lies, in time, after the arrival.

Example:

Goods receipt:

Montag 15:00

next appointment:

Dienstag 08:00

This first sets:

pruefung_geplant_am = Dienstag 08:00

.

A goods receipt of:

Dienstag 10:00

has already missed this appointment.

The next possible appointment is therefore:

Donnerstag 08:00.

The Forge first calculates this natural or planned appointment independently of the available capacity.

6. Defining capacity via inspection stations

Under:

3. How much fits into one appointment?

choose, at:

Set capacity via

the option:

Capacity per role/group

We use two inspection stations:

This way, per inspection appointment, a total of:

16 inspections

can be processed.

The full P2P configuration uses exactly these two inspection stations, each with a capacity of 8.

[SCREENSHOT: Prüfplatz 1 and Prüfplatz 2 with capacity 8]

Capacity per case

As the:

Unit

we use:

Cases (count)

This way, each goods-receipt inspection requires exactly one capacity unit.

An inspection appointment with a total capacity of 16 can thus accommodate a maximum of 16 inspections.

7. Enabling the backlog

Enable:

Backlog

Now limited capacity actually becomes a queue.

Suppose that for Tuesday there are:

20 Prüfungen

queued.

The available capacity is:

16

Then:

16 Prüfungen

are processed on Tuesday.

The remaining:

4 Prüfungen

slip to the next available appointment:

Donnerstag 08:00

In doing so, the engine works through the waiting transactions according to their arrival order and moves transactions that no longer fit into later appointments.

[SCREENSHOT: Backlog enabled]

What becomes visible in the data set?

A transaction without a bottleneck can look like this, for example:

pruefung_geplant_am = Dienstag 08:00

wareneingang_geprueft_am = Dienstag 08:00

verzoegerung_slots = 0

pruefkapazitaet_ueberschritten = 0

A transaction with a backlog, by contrast:

pruefung_geplant_am = Dienstag 08:00

wareneingang_geprueft_am = Donnerstag 08:00

verzoegerung_slots = 1

pruefkapazitaet_ueberschritten = 1

If Thursday, too, becomes fully utilized, a transaction can accordingly be pushed back even further.

This produces no artificial fixed delay, but a delay arising from the actual ratio of:

work volume

and

available capacity.

Assignment to the inspection station

The processed inspections are additionally assigned to one of the configured inspection stations:

Prüfplatz 1

or

Prüfplatz 2

The value is stored in:

pruefplatz

.

This later allows investigating, for example:

How heavily are the individual inspection stations utilized?

or:

Which transactions had to wait for a later appointment because of the bottleneck?

Optional inspection-batch object

The full Expert configuration can additionally generate a dedicated object:

pruefbatch

.

In doing so, inspections that were processed at the same appointment and at the same inspection station receive a common batch object.

For understanding the capacity bottleneck, this additional object is not strictly necessary.

The central relationship remains:

Wareneingang

→ next possible inspection appointment

→ limited capacity

→ possibly a backlog

→ actual later inspection appointment.

Generating the Capacity Bottleneck SQL

The capacity configuration does not change the already-generated data directly in the browser.

Instead, 07 Capacity Bottleneck generates an additional SQL script.

The intended order is therefore:

data.sql

→ execute on SQL Server first

then:

Capacity Bottleneck SQL

→ execute on the same data.

The generated capacity script is explicitly intended to be executed after the normal data SQL.

[SCREENSHOT: generated Capacity Bottleneck SQL]

What should I later see in Noreja?

In process mining, cases with clearly different waiting times before the goods-receipt inspection should now become visible.

Particularly interesting are relationships between:

wareneingang_gebucht_am

pruefung_geplant_am

wareneingang_geprueft_am

and:

verzoegerung_slots.

This allows investigating questions such as:

How many inspections could not be carried out at the first possible appointment?

How large is the average backlog?

At which inspection appointments does a capacity overrun arise particularly often?

How strongly does the bottleneck influence the cycle time of the physical procurement path?

Unlike with our earlier supplier rule, the delay here does not arise from a directly set time factor.

It arises from the interplay of arrival time, fixed processing appointments and limited capacity.

Common mistakes / things to watch out for

Enable the backlog. 
Without a backlog, no genuine queue across multiple inspection appointments arises.

Store the planned and actual appointment separately. 
Only this way can it later be traced whether an inspection was postponed.

Interpret capacity per role/group correctly. 
With two inspection stations of 8 each, the effective total capacity is 16 inspections per appointment.

Execute the capacity SQL after data.sql. 
The bottleneck is applied as a downstream SQL transformation on the already-generated data.

Result

We have now modeled a real resource-driven bottleneck for the first time:

Wareneingänge treffen ein

→ inspections are only possible on Tuesday and Thursday

→ per appointment, 16 slots are available

→ capacity is exceeded

→ transactions move to the next appointment

→ a backlog arises.

With this, our synthetic process has a delay that is not simply predefined, but arises from a realistic capacity restriction.

Next step

So far, the bottleneck affects only:

wareneingang_pruefung

directly.

In the next Expert use case, we ask the decisive causal question:

What happens to the rest of the process when the goods-receipt inspection is delayed?

For this, we enable:

Delay Propagation

and transfer the delay that has arisen to the invoice and payment.

Next: Tutorial P2P -  Delay and Loss of Cash Discount