Skip to main content

Hi all,

 

suppose I have the following activities in my process (there can also be other activities in the process but they are irrelevant for the cycle time calculation):

  • Send PO
  • Change Price, and
  • Receive Vendor Confirmation

 

---------------

 

In my process, possible process variants are:

 

1.Send PO --> Change Price --> Send PO --> Receive Vendor Confirmation

 

or

 

2. Send PO --> Receive Vendor Confirmation

 

or (and this is where things get tricky)

 

3.Send PO --> Change Price --> Send PO --> Change Price --> Send PO --> Send PO --> Receive Vendor Confirmation

 

 ---------------

 

-> My goal is to find an expression that always calculates the cycle time between the FIRST Send PO activity that happens after the LAST Change Price occurred and the FIRST Receive Vendor Confirmation activity.

Now, it is relatively easy to define the second part of the cycle time calculation because I can simply take PU_FIRST for the Vendor Confirmation activity. However, I am unsure how to receive the correct Send PO activity of the cycle time calculation. For process variants 1. and 2. I could easily take a PU_LAST for the Send PO activity, however for the 3. process variant there are two Send PO activities after each other without intermediate price changes. Here, I can not simply take the PU_LAST because this would give me a timestamp of the LAST Send PO activity. I am looking for a statement that also includes process variant 3. to be calculated correctly.

 

-> I have marked the correct activities (bold) in the three process variants above for which I would like to define a general statement for cycle time calculation.

 

This is what I have so far:

 

DAYS_BETWEEN (

  PU_LAST (

    "EKPO" ,

    <%= MEL_timestamp_column %> ,

    <%= MEL_activity_column %>

    =

    'Send Purchase Order'

  ) ,

  PU_FIRST (

    "EKPO" ,

    <%= MEL_timestamp_column %> ,

    <%= MEL_activity_column %>

    =

    'Receive Vendor Order Confirmation'

  )

)

 

@david.beche12​ I would highly appreciate your input here as this use case is business critical at our customer...

 

Many thanks in advance,

 

Florian

Hi,

 

you first need to "mark" all "Send PO" Activities which are possible candidates, i.e. which come after a "Change Price", and not after a "Send PO". You can do this with ACTIVITY_LAG:

 

ACTIVITY_LAG( CASE WHEN "Activities"."Activity" IN ( 'Change Price', 'Send PO' ) THEN "Activities"."Activity" END )

 

When the result of this is "Change Price", the current row is a possible candidate, if it's "Send PO", it's not. We want the last candidate, and the candidate should itself be a "Send PO", so we can formulate the following PU_LAST:

 

PU_LAST("Activities_CASES", "Activities"."timestamp", "Activities"."Activity" = 'Send PO' AND ACTIVITY_LAG( CASE WHEN "Activities"."Activity" IN ( 'Change Price', 'Send PO' ) THEN "Activities"."Activity" END ) IN ( 'Change Price' ) )

 

Unfortunately this would not take the second case into account, where there is no "Change Price" followed by a "Send PO". In this case, we return the last (or first? You need to specify this case as well) "Send PO":

 

COALESCE (

PU_LAST("Activities_CASES", "Activities"."timestamp", "Activities"."Activity" = 'Send PO' AND ACTIVITY_LAG( CASE WHEN "Activities"."Activity" IN ( 'Change Price', 'Send PO' ) THEN "Activities"."Activity" END ) IN ( 'Change Price' ) ) ,

PU_LAST("Activities_CASES", "Activities"."timestamp", "Activities"."Activity" = 'Send PO' )

)

 

 

This should give you the timestamp of the "Send PO" you want. Now you need to put this in the first argument of your DAYS_BETWEEN and it should work fine.

 

Best

David


Hi @david.beche12,

 

thanks a lot for the quick reply!

 

I understand your solution and I like the distinction with COALESECE() to basically route depending on whether change prices occur or not.

 

One follow-up question:

AFAIK ACTIVITY_LAG() only checks the direct predecessor activity, correct?

 

What if we have a fourth variant with arbitrary other activities between the last Change Price activity and the Send PO activity of interest for the cycle time calculation, such as:

 

4.Send PO --> Change Price --> Send PO --> Change Price --> "arbitrary other activity(ies)" --> Send PO --> --> Send PO --> Receive Vendor Confirmation

 

In order words: the Send PO activity of interest does not necessarily have to occur DIRECTLY after the last Change Price activity but EVENTUALLY after it (with arbitrary other activities in between but no intermediate activities Change Price or Receive Vendor Confirmation).

 

Here we need something else than ACTIVITY_LAG to define the Send PO activity of interest?

 

Best,

 

Florian


Hi Florian,

 

it should be fine, because ACTIVITY_LAG skips NULL values, i.e. it returns the direct predecessor which is not NULL. With the CASE WHEN inside the ACTIVITY_LAG, I set all other activities to NULL, so they should not influence anything.

 

Best

David


HI @david.beche12,

 

you are right - Indeed your proposed statement already considers process variant 4. I have checked specific cases in my process and it works fine.

 

Once again, thanks ALOT for your help on this case.

 

I highly appreciate it,

 

best and good weekend,

 

Florian

 

 


Reply