I follow up on my previous blog post, Create Process Definition for Business Process Monitoring and Analytics for Business Suite Processes (POB), on how to set up a process definition for POB with an explanation on how to set up KPIs. I’m building on the example in that blog post, i.e. I define the KPIs for the process previously defined, so some basic understanding of what a process definition looks like is probably required to understand the following. You may also want to look at the introductory blog post, Introducing New Component: Business Process Monitoring and Analytics for Business Suite Processes (POB), or the overall architecture, Architecture of Business Process Monitoring and Analytics for Business Suite Processes (POB)) of the component.
Nevertheless, allow me to reintroduce the example and add the KPIs I want to measure:
For this example, I want to count changes to a sales order and the duration between creation of a sales order and the creation of the outbound delivery.
You define the key performance indicators (KPIs) at the process definition level. They will then be calculated in real-time while process monitoring is happening. Three types of KPIs can be defined for a process:
- Count: Calculates the number of times an activity is executed, for an example see below.0.1.
- Duration: Calculates the amount of time that elapses between activity executions, for an example see below.0.1.
- Classification (not a real KPI): Calculates a classification code, based on a user-defined BRFplus rule, for the process instance. The classification can, for example, be used for analytics; we will not cover this in this blog post.Let me start with two examples and then continue with some general considerations.
A short note on release dependency: the screens may look slightly different depending on version (and support package level). This is a rather new development, so some things still do change; none of the changes should cause any problems when trying to re-create these examples, should you try.
Create (or define) a KPI to count the changes to the sales order
Since the KPIs are part of the process definition, execute transaction Maintain Process Definition (POC_MODEL) as for the process definition (see the previous blog).
Navigate to the “Count KPIs” view of the view cluster – and again, I assume that you have a basic working knowledge of view clusters, but I’ll point out that you need to mark the version and the click the “Count KPIs” in the dialog structure:
As you can see, KPI definitions are version-dependent.
Create New Entries button to create the count KPI as follows:
- KPI Definition ID: 1
- KPI Type: Count
- KPI: Count Changes to Sales Order
- Activity: 20CHNGSO
- Determiner: <not used>
- Determiner Activity: <not used>
Note that you can use the Input Help (F4) to select the activity.
The definition ID is just “some ID”; it is needed, because you can have more than one (count) KPI for a given process definition.
This means all occurrences of activity 20CHNGO will be counted for a process instance and can be accessed with KPI Definition ID 1 (Count Changes to Sales Order).
Even though we have are not using it, let me explain the “Determiner” here. The possible values are “Before first” and “After first” (and who knows what will become available down the road) and it works with the “Determiner Activity”. So what you can set up is “Count the activity Counter Changes to Sales Order after the activity Create Outbound Delivery was executed the first time” and similar KPIs. I’m using the simpler case, not because it is simpler to set up (it’s not), but because eventually it’s easier to re-create when you actually run the process.
Create (or define) a Duration KPI
To define a duration KPI you proceed in a similar way to the count KPIs. Go to the “Duration KPIs” in the dialog structure of the view cluster and choose the New Entries button to create a duration KPI.
Enter the following information:
- KPI Definition ID: 2
- KPI Type: Duration
- KPI: Duration SO creation to OD creation
- Start Activity: 10CREASO
- Start Determiner: <not used>
- End Activity: 30CREAOD
- End Determiner: <not used>
You have now set up a KPI to track the duration of the process from the (first) sales order creation to the (first) order delivery creation, which looks like this:
As for the count KPIs, you have a determiner, in this case start and end determiner of either “First” or “Last”. The defaults are “First” for the start and end activity. Using this, you can measure duration from “Last change of sales order” to “creation of delivery” etc.
“First” is actually the default setting, if not determiner is defined.
KPI Definition Considerations
There are some general thoughts about KPIs that may help you understand what they can do and how they work.
KPIs defined in the process definition are not calculated retroactively. So if you create a new KPI for an existing process definition, it will only be available for new or currently running processes. If you change the definition of an existing KPI, the calculation is only changed for new or running process instances. That is one reason why you would want to create a new KPI rather than changing the definition of a KPI.
The KPIs defined here and calculated at runtime are also available via extractors for the SAP BW and other consumers, and for other consumers (see blog on architecture). Using the native capabilities of these external components, you can – of course – do aggregations, or calculate new, additional KPIs based on the extracted POB data. Details of data extraction and BI Content will be explained in a separate blog.
You will find that you need to build your model in such a way that you can actually define the KPI that you want to measure. You must have a distinct activity for each “point of measurement”, be start or end of duration or determiner. So if you need to count “Changes to requested delivery date of a sales order” you need a separate activity of that kind (and I’ll show you in one of these blogs how to set that up easily).
Finally, one of the first things that come to mind when looking at this is the use of KPIs as part of service level agreements (SLAs). While SLAs can be quite complex, a seemingly simple functionality in this area is that of thresholds to KPIs that trigger some activity. This is not part of the last delivery, but you may want to watch this blog.
If you have any questions on KPIs or process observer, let us know! We are happy to receive feedback and discuss you topics.