Hey everyone,
I thought I would share as a separete blog after responding to a question, in order to have a relevant entry title.
Depending on the Process that are being analysed, perhaps there is a need to be more specific on the what is the period to consider between first and last timestamps of each case in the process (c_caseid).
For example, the Average Cycle Time standard query, just takes the difference between the timestamps considering all days are working days.
as below sample:
( Note 1, i made a copy of the standard one, as I will adjust its query and rename it “Net Average Cycle Time MTWTF” which is usefule for Europe for example )
(Note 2, I recommend that anyone would identify the calendar days in the metric name, because for example, a company that has operations in Israel, would have to use a “Net Average Cycle Time SSMTWT (sunday to thursday) )
The SIGNAL function DURATION_BETWEEN and the relevant CALENDARIDs can be relevant to modify the query of a metric to use the relevant weekday calendar
I wanted to test this function against a simple dataset and just see the results it would return in a SIGNAL table, to analyse how it works and better understand how to use it later in any queries related to Metrics or for other transformations in a pipeline business object.
This is the simple dataset: (very simple, just so I could analyse 4 cases against the event timestamps)
In order for me to try to verify the results of DURATION_BETWEEN, i thought I would that by also bring in the results of another helpful function DATE_PART and use its attribute ‘day_of_week’, which identifies which day of the the timestamp is.
The returns of ‘day_of_week’ follow the below logic:
I created a test SIGNAL table widget to play with the above functions to have a better idea how they can be used in Metric queries
In the table I wanted to identify day of the week per event timestamp per case.
Note: the query i used, is not including the AVG yet, which is part of the standard Average Cycle Time metric. because this is table to analyse each case (c_caseid) and verify the results.
So I threw all the functions on one query, DATE_PART, DURATION BETWEEN and the regular query for Cycle Time seen in most metrics in the PI Metric Library.
Which brings the following results based on the test dataset shown in the table widget
The above results served to corroborate that DURATION_BETWEEN is a helpful function that can be used in adjusting Metrics where is needed to be more specific regarding weekday calendar is needed.
As in the example above for Average Cycle Time, DURATION_BETWEEN can be used in the metric query and a copy can be renamed as such
About the Author
JD Wong-Loera is a Stockholm/Toronto based Project Manager, Business Architect and Process Managament consultant who enjoys supporting others in understanding the Businesss Architecture and Business Process Management Capabilities. In his free time he enjoys camping, reading and boxing.
Check out my other blogs at: About JD_WongLoera – SAP Community
Hey everyone,I thought I would share as a separete blog after responding to a question, in order to have a relevant entry title.Depending on the Process that are being analysed, perhaps there is a need to be more specific on the what is the period to consider between first and last timestamps of each case in the process (c_caseid).For example, the Average Cycle Time standard query, just takes the difference between the timestamps considering all days are working days.as below sample:( Note 1, i made a copy of the standard one, as I will adjust its query and rename it “Net Average Cycle Time MTWTF” which is usefule for Europe for example )(Note 2, I recommend that anyone would identify the calendar days in the metric name, because for example, a company that has operations in Israel, would have to use a “Net Average Cycle Time SSMTWT (sunday to thursday) ) The SIGNAL function DURATION_BETWEEN and the relevant CALENDARIDs can be relevant to modify the query of a metric to use the relevant weekday calendarI wanted to test this function against a simple dataset and just see the results it would return in a SIGNAL table, to analyse how it works and better understand how to use it later in any queries related to Metrics or for other transformations in a pipeline business object.This is the simple dataset: (very simple, just so I could analyse 4 cases against the event timestamps)In order for me to try to verify the results of DURATION_BETWEEN, i thought I would that by also bring in the results of another helpful function DATE_PART and use its attribute ‘day_of_week’, which identifies which day of the the timestamp is. The returns of ‘day_of_week’ follow the below logic:I created a test SIGNAL table widget to play with the above functions to have a better idea how they can be used in Metric queriesIn the table I wanted to identify day of the week per event timestamp per case. Note: the query i used, is not including the AVG yet, which is part of the standard Average Cycle Time metric. because this is table to analyse each case (c_caseid) and verify the results.So I threw all the functions on one query, DATE_PART, DURATION BETWEEN and the regular query for Cycle Time seen in most metrics in the PI Metric Library. Which brings the following results based on the test dataset shown in the table widgetThe above results served to corroborate that DURATION_BETWEEN is a helpful function that can be used in adjusting Metrics where is needed to be more specific regarding weekday calendar is needed.As in the example above for Average Cycle Time, DURATION_BETWEEN can be used in the metric query and a copy can be renamed as suchAbout the AuthorJD Wong-Loera is a Stockholm/Toronto based Project Manager, Business Architect and Process Managament consultant who enjoys supporting others in understanding the Businesss Architecture and Business Process Management Capabilities. In his free time he enjoys camping, reading and boxing.Check out my other blogs at: About JD_WongLoera – SAP Community Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
+ There are no comments
Add yours