Tutorial P2P - Error Pattern: Order Before Final Approval - Wrong Order

TL;DR 
Goal: Generate cases in which an order lies, in time, before a required approval. 
Prerequisites: The approval structure with DUAL and DIRECT is in place. 
Result: In a portion of the approval-required cases, bestellung lies, in time, before freigabe_b.

The business question

In the regular procurement process, an approval-required order should only be created after the necessary approvals have been given.

The expected sequence is:

Bestellanforderung

→ Freigabe A / Freigabe B

→ Bestellung

A possible compliance deviation, by contrast, is:

Bestellanforderung

→ Bestellung

→ Freigabe B

The approval is not completely missing here. It merely happens too late.

This is exactly where this use case differs from maverick buying.

Maverick buying vs. wrong order

With maverick buying, an intended approval path is bypassed.

With wrong order, the approval still takes place – but in the wrong temporal sequence.

Maverick Buying

Bestellanforderung → Bestellung

Approval is skipped.

Wrong Order

Bestellanforderung → Bestellung → Freigabe

Approval is present, but happens only after the order.

This generates a different kind of compliance problem.

1. Creating a wrong-order rule

Open:

04 Special Behaviour

and add a new Add deviation rule.

Choose:

Type: 
Wrong order (swap two slots)

The Smart Data Forge uses Wrong order to swap the timestamps of two process slots with one another.

2. Selecting the two process steps

Choose:

Slot A: 
freigabe_b

and:

Swap with: 
bestellung

This defines which two process events are to swap their temporal position.

In the normal case the following applies:

freigabe_b

→ bestellung

In the wrong-order case the following arises:

bestellung

→ freigabe_b

What is actually changed in the process?

Wrong order does not change the relational structure of the data set.

Foreign keys, table relationships and the actual Causal Chain remain in place.

Instead, the timestamps of the two selected slots are shifted in time after the normal data generation. The engine applies such deliberately generated wrong-order anomalies only after the regular causal timestamp generation.

This deliberately gives us data in which:

the relationship still exists in business terms, but the temporal sequence is no longer plausible.

It is exactly such cases that are particularly interesting for process mining.

3. Applying wrong order only to approval-required cases

Here we have to take into account a particularity of our P2P model.

freigabe_b exists only on the:

DUAL

path.

In a regular:

DIRECT

case there is no freigabe_b.

We therefore want to avoid a DIRECT case being selected as wrong order, even though no second approval is intended there at all.

For this we first set, on the wrong-order rule:

Probability (%): 5

This way the following applies:

If a freigabe_b exists for the case, there is a probability of 5% that its temporal sequence with the order is swapped.

5. Flagging the deviation

On the wrong-order rule, set as the:

Tag:

BESTELLUNG_VOR_FINALER_FREIGABE

The finished configuration

Wrong-order rule

What changes in the data set?

Without deviation:

Bestellanforderung

→ Freigabe A / B

→ Bestellung

With wrong order:

Bestellanforderung

→ Bestellung

→ Freigabe B

The important point is:

The approval was not removed.

It is still present, but lies, in time, after the order.

This deliberately generates a case in which the process structure and the time logic no longer match one another.

What should I later see in Noreja?

In Noreja, individual approval-required cases should become visible in which the order was already placed before the required approval.

Possible analysis questions are:

How many orders were created before the approval was completed?

Which requesters, product groups or order values occur particularly often in these cases?

What effects does the wrong sequence have on the rest of the process?

Particularly interesting here is the comparison with maverick buying:

Maverick Buying: approval is missing.

Wrong Order: approval exists, but comes too late.

This allows two process anomalies that appear similar to be cleanly separated from one another in business terms.

Common mistakes / things to watch out for

Do not confuse wrong order with overjump. 
We do not want to remove the approval, but merely change its temporal position.

Only consider approval-required cases. 
A DIRECT case without freigabe_b is not a wrong-order case.

The relational structure remains in place. 
Wrong order manipulates the timestamps – not the foreign keys or the causal chain.

Result

Our data set now additionally contains a genuine temporal process deviation:

erforderliche Freigabe

→ should take place before the order

becomes, in selected cases:

Bestellung

→ Freigabe

With this, alongside missing activities, performance problems and rework, we now also have a sequence violation in the synthetic P2P data set.

Next step

Next, we model processes that do begin regularly but do not run through to the end:

Process abort / open processes

For this we use the Abort behaviour and deliberately have cases end after various process steps.

Next: Purchase-to-Pay Error Pattern Process Abort or Open Processes