Using the Analytics page
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:
The standard widgets such as Bar chart, Pie chart, Table, and Card that you can configure with a low-code query script.
-
Preconfigured widgets:
Widgets such as Process model, Lead time distribution, and Case KPI summary that are pre-configured in IBM Process Mining. However, you cannot customize these widgets.
-
Custom widgets:
Widgets that you can use to design backend and frontend logic and the graphical representation using the JavaScript code.
This section is focused on configurable widgets.
To learn more about widgets, visit configuration and queries.
The core concepts you must keep in mind are:
- Measures are the quantitative statistics, custom metrics, 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) or custom metrics, 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: IBM 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 example:
- #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 example:
- 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 example:
- 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 example:
- 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: