jens-christoph.nolte ...

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’re happy to receive feedback and discuss you topics.

While this is the fifth blog post in the series of "Business Process Monitoring & Analytics for Business Suite Processes (POB)”, it is my first blog post on this topic.

The previous posts of the series have been Introducing New Component: Business Process Monitoring and Analytics for Business Suite Processes (POB), explaining the Architecture of Business Process Monitoring and Analytics for Business Suite Processes (POB), and have given an example in Monitor Sales Order Processing with Business Process Monitoring and Analytics for Business Suite Processes (POB).

Now that the system is up and running, after the Setup of Component Business Process Monitoring and Analytics for Business Suite Processes (POB), let’s move on to the heart of matters:

Creating a Process Definition

This blog is based on a hands-on TechEd session. If you missed it, here is a short version based on the assumption that you have some basic knowledge from the previous posts.

The process we want to create a definition for is – for the sake of argument - this short order to delivery process:

If you are not familiar with the process, you can probably set it up in your system, but you may have some problems executing it in the system. I can’t help you with that, as the set-up of your sales order (materials etc.) will be very specific to your customizing.

In the following, I’ll go through the steps of creating the process definition in some detail.

Create the Process Definition Header

The process definitions are maintained using a standard view cluster that is enhanced with some functions. To start, execute transaction Maintain Process Definition (POC_MODEL). The transaction is part of the standard user role (SAP_POC_BPX).

All data you enter is standard customizing data. SAP delivers some template data that may be available in your client. As for all customizing data, you may need a transport request to save data.

To start, choose the New Entries button to create a process definition header and enter an ID and a description, let’s say PMC264_SalesOrderProcess00 and “Sales Order Process”. (We don’t want to enter a current version or set the log-level yet as we’re still in process of setting up the process definition. We’ll come back to these steps later.)

Create the Version

As always when navigating through view clusters – and I won’t repeat this every time we navigate down – be sure to select your process definition table row and then double click Process Version in the navigation tree.

Choose the New Entries button to create a process version. Enter a numeric value “1” for the version and activate this process definition version by clicking the checkbox in the Active column.

A word about versions: for a Process Definition you can create multiple versions; the current version is used for new process instances, but for existing process instances, the version in which they were started is used. That way you can consistently change the process definition. This is a technical function that you can use to manage the life cycle of your process definitions – and one reason to do process monitoring is process optimization, i.e. “change” – but there are other things to consider.

Now you can go back to the process definition header and enter the version number as the “current version”.

Add Activities to the Process Definition

From the versions tables, you can create the activities. “Activities” is the term we use and it is based on BPMN terminology. What we call “activities” is often also referred to as “steps”.

Choose the New Entries button to create activities. Enter the following activities (the IDs don’t have to start with a number, but it is convenient for putting them in the correct order):

10CREASO Create Sales Order as a Start activity
20CHNGSO Update Sales Order
30CREAOD Create Outbound Delivery
40CREATO Create Transfer Order as an End activity

The start indicator is very important. Without a start activity, the logging of a process instance will not be started. The status of a process where a start activity was executed is “Started”. The end indicator is used for the status of the process: if an end activity is reached, the status of the process instance will be “Finished”; a process may be “Restarted” though, by any activity that follows an end activity. Any other activity will change the status to the status “Running”. This already covers the simple default status handling: Started, Running, Finished, and Restarted.

You can have multiple start and end activities. Multiple start activities can be used if your process either starts with the creation of a quote of a sales order; then both activities, create quote and create sales order, can be marked as start activities. When a sales order is created and no predecessor – in this case a quote – is found, a new process instances is created. If a predecessor is found, the activity will be linked to the existing process instance and no new process instance is created.

The result should look like this:

Assign the Tasks to the Activities

You now have a process definition. The definition is at this point not linked to any runtime object. So the next step is to link the definition, or “model”, to the runtime. To do that, you have to assign (at least) one task (event) to each activity. At runtime, the events are mapped to the activities. The tasks themselves are linked to BOR events, which are actual runtime objects: BOR events actually occur at runtime, the can be stored and processed. You can create new tasks in the PMA façade layer. This will be explained in a separate blog.

For each activity definition navigate down to the task assignment.

Activity Create Sales Order (10CREASO) should be assigned to Task Create Sales Order (Business Object Type 114 Task Type ID 21); that would look something like this:

Activity Create Sales Order assigned to Task Create Sales Order

You have to go back to the activities and repeat the steps of assigning tasks for the remaining three activities:

Activity Update Sales Order (20CHNGSO) should be assigned to Task Update Sales Order (Business Object Type 114 Task Type ID 88).

Activity Create Outbound Delivery (30CREAOD) should be assigned to Task Create Outbound Delivery (Business Object Type 73 Task Type ID 21).

Activity Create Transfer Order (40CREATO) should be assigned to Task Update Outbound Delivery (Business Object Type 73 Task Type ID 88). This last assignment is probably not the best way of doing it, but for this rather simple example, it is good enough.

When you actually look at the view in your system, you will find here - and in some of the other views - a reference to Business Rule Framework plus rules. These rules add a lot of flexibility; in this view they allow you to do the "binding" between task and activity based on a condition that is put in the rule e.g. you want the create event to bind to your activity only for certain customers; you can then add a rule to do that.

Set up Callable Business Entity Assignment [Optional]

Sometimes the easiest way to describe a process is the sequence of screens you go through, or in SAP terms, the sequence of transactions. The Callable Business Entity is “the transaction”, but it can also be an automatic task that is described as a web service call.

You can add here the appropriate transactions for each activity, in our case the transactions VA01 to create a sales order, VA02 to update it, VL01N to create the outbound delivery and finally VL02N to create the transfer order.

Sometimes it is a valid approach to create a process definition by starting with the order of transactions being carried out.

Set up Activity Sequence [Optional]

By setting up the sequence, you can make sure that the presentation, e.g. in the process definition viewer (POC_VIEWER), is in the order defined here. This is for your convenience and does not affect the runtime.

Navigate to the Activity Sequence Flow in the navigation tree and create New Entries and enter a true sequence flow going from 10CREAS to 40CREATO.

The result, the Activity Sequence Flow for the sample process definition, should look like this:

Note that you may have multiple “next“ or „previous“ activities for a given activity, so parallel flows, for example, are possible. You are not protected from setting up random sequences, but since this is used for presentation purposes only, it wouldn’t do much except disrupt the presentation.

You are now finished with setting up the process definition. We can now have a look at the process definition using the Process Definition Viewer (POC_VIEWER), which displays the definition in a much more comprehensive way than the view cluster can. In higher releases, the viewer is available as a web dynpro screen as well.

Topics we have not covered here are KPIs, setting up a complex process status handling, the rules in the various places and the extension concept, and federation (setting up process chains across multiple systems). We will look at those in separate blog posts.

Check the Definition

After setting up your process definition, you need to check the model to see if you have any errors in your definition. Transaction Process Definition Checks (POC_MODEL_CHECK) is helpful for finding issues. Start it with your process definition ID, which in this example is PMC264_SALESORDERPROCESS00.

You should receive as a result of the process definition check something similar to this:

If you have a red X in the consistency column, you’ll need to look into the issues reported.

The following common errors are reported:

Process definitions without an active version
Activities with inactive Business Object Repository (BOR) events
No start activity assignment
No task assigned to activity
No BOR event or class assignments

If you encounter any errors, such as a missing start activity, you can navigate back to your process definition by choosing View-cluster button to make your corrections.

For this example, your process definition should to be consistent (error-free) before proceeding. In practice and with more complex examples there may be reasons why you want to do things that lead to warnings, e.g. insert activities that are not assigned to any task for documentation purposes.

Switch on Logging

Finally, you want to switch on the logging. To do that, on Process Definition Header level set the log level to “Standard logging”. You can now run the process: using transaction VA01, you create a sales order (do that only in your test system and when you know that you are not affecting anybody else), call the process monitor (POC_MONITOR) and you should see something like this (this is actually after having executed the first three steps of the process):

Again, in higher releases there is a web dynpro version of the monitor available.

Now that you understand how to set up a process definition, we’ll look into KPI functionality and definition in Create KPI Definitions for Business Process Monitoring & Analytics for Business Suite Processes (PMA).