Overview of How Analytics Work
Analytics platform allows you to create custom dashboards by dragging and configuring widgets according to the analysis that you want to perform.
You have 3 types of widgets:
-
Configurable widgets: these are the standard widgets you can configure with a low-code SQL-like approach.
- Bar chart, Pie chart, Table, Card andmany others.
-
Preconfigured widgets: these are widgets made available by IBM Process Mining –every preconfigured widget has its own configuration, but generically speaking you don’t have total control of what the widget will display.
- Process model, Lead time distribution, Case KPI summary and many others.
-
Custom widgets: these are widgets created by the end users, who have the possibility to design both backend and frontend logics and the graphical representation, using JavaScript code.
This section is focused on configurable widgets.
To learn more about widgets, visit configuration and queries.
The core concepts you should keep in mind are:
- Measures are the quantitative statistics and KPIs you want to measure.
- Dimensions are the elements you want to focus on while you measure the KPIs(for example, vendors, plants, materials), for comparison and correlation purposes.
- Filters are expressions you use to focus only on specific process events, while measuring the KPIs.
- Note: always consider the filtering hierarchy: process mining filters --> dashboard filters --> widget filters.
- Check this article for further explanations.
All the widgets of Analytics are based on the Eventlog as unique source of data.
While you are configuring awidget, always consider the Eventlog as a table on which you are performing queries.
Widget configuration scenarios and examples
This section includes several examples of widget configurations and measures.
Let’s start from the following sample eventlog (you can download the eventlog from this link).
The eventlog includes:
- Mandatory fields: ProcessID, Activity and StartTime;
- Optional fields: Resource and Role, which are by definition event-level attributes (the field value is associated to the event and may change across the same case);
- Custom field: TicketType, which is a case-level attribute (the field value is associated to the case and is typically fixed across the same case);
- Custom field: CustomerRating, which is an event-level attribute present only on the activity “Complete”.
Count KPIs:
Statistics based on counting, for instance:
- #resources/roles
- #ticket types
- #cases
Example: the user wants to understand how many different roles are involved within the process:
-
Measure: count(distinct(role))
- Without any dimension, this counts the distinct roles involved in the process.
-
The measure is equal to the number of distinct values present in the “Role” column.
-
Add Dimension: “TicketType”
-
This counts the distinct roles involved for every ticket type
-
-
Change Dimension: “Activity”
-
This counts the distinct roles involved for every activity
-
-
Add Widget Filter: role <> 'Bot'
- This counts the distinct roles involved for every activity (or ticket type), excluding the Role “Bot” from the count.
-
Concretely, the filters exclude the eventlog records where the column Role = “Bot”.
-
In the example, this is excluding “Notify Customer” activity from the dataset, since it is always performed by Bot
Performance KPIs
Statistics related to performance, for instance:
- Activity execution time
- Activity waiting time
- Event cost
- Path time
Example: the user wants to calculate the average waiting time for the process activities.
-
Measure: avg(waittime)
- Without any dimension, this computes the average waiting time on the overall (not so relevant).
-
The measure is equal to the time elapsed between the execution of the previous activity and the start of the current one.
-
Add Dimension: “Activity”
-
This computes the average waiting time for every activity
-
-
Add Dimension: “Resource”
-
This computes the average waiting time for every activity and every resource involved
-
-
Add Widget Filter: tickettype = 'Product issue'
- This considers only the “Product issue” ticket type in the computation.
-
Concretely, the filters exclude the eventlog records where the column TicketType is not “Product issue”.
-
Here’s the resulting query:
Other Custom KPIs
Statistics calculated on quantitative custom fields, for instance:
- Amount
- Customer Rating
- Price
- Payment Timeliness
Example: the user wants to calculate the average customer rating.
-
Measure: avg(customerrating)
- Without any dimension, this computes the average customer rating.
-
The measure takes in consideration every record with non-null “CustomerRating” field.
-
Add Dimension: “TicketType”
- This computes the average customer rating time for every ticket type.
-
The average rating is not displayed for “DevOps activity request” ticket type, as it has no records with non-null “CustomerRating” field.
-
Add Widget Filter: activity = 'Complete'
- If you know that a custom field is filled only on a specific activity, you may want to focus only on that activity to perform the computation.
-
Concretely, the filter includes only the eventlog records where the column Activity = “Complete”
-
Here’s the resulting query:
Case-level KPIs
Statistics associated to a case, for instance:
- Process Lead Time
- Process Cost
- Other custom KPIs, if case-level quantitative custom fields are available in the Eventlog
Example: the user wants to calculate the average process lead time.
-
Measure: avg(casedistinct(leadtime()))
-
leadtime() is a function, which associate to a case (and all its events) a unique value = time elapsed between the start of its first activity and the completion of its last activity.
-
You MUST use casedistinct inside the formula for case-level KPIs, since you are not computing the average at event level.
-
-
Add Dimension: “TicketType”
- This computes the average process lead time for every ticket type.
-
It’s recommended to use case-level attribute as dimensions for case-level KPIs.
-
Add Widget Filter: activity = 'Complete'
- This considers in the computation only the processes where “Complete” activity occurred.
-
Concretely, the filter includes only the eventlog records where the column Activity = “Complete”
-
This doesn’t affect the leadtime() computation, since it is a function at case-level.
-
Here’s the resulting query: