|
How to Create an Event Log for OCPM |
Scroll Previous Topic Top Next Topic More |
The main differences between the traditional event log and the object-centric event log are:
1.One process can have several objects, which bring their own type of Case ID. Hence, the Case ID is no longer one common identifier for the process instance to which all events are related but the identifier for the object itself, which caused the event to happen. For this reason, the former process instance is now captured in the new field Link in the CaseInformation table, while the object ID is captured in the field CaseID. To decide which CaseID belongs to which type of object, a new field ObjectType is implemented.
2.To see the interaction of objects in the ProcessAnalyzer some key activities are used as touchpoints, which means that an activity which originates from one object, is also shown in the process flow of another object. Example: items are packed into one package. In this case the touchpoint activity between the item and the package object could be "pack item", which originates from the item object but is also used in the package object to reflect the interaction or better said touchpoint between the two objects. The new field PrincipalObjectType has been implemented to keep the information from which object an activity was originally caused.
3.To keep the information from which source an event stems, the field ActivityOriginID is now obligatory. Furthermore, by tracking this information the counts on number of events are always correct when referring to this unique event identifier. Most important is the correct use of the ActivityOriginID when the activities are used as touchpoints. Here, the ActivityOriginID is the same ID when used in different objects, to prevent duplicates when counting or analyzing events.
| This table shows the new fields and their purpose. We see three different caseIDs, which come from two item objects and one package object. The three objects are related via the Link field, which contains in this example the customer order ID. The field ObjectType holds the information of the object type for the CaseIDs. The ActivityType and ActivityStartTimestamp fields are well known. Finally, the purpose of the PrincipalObjectType and the field ActivityOriginID become clear when you take a closer look onto the blue highlighted cells. The two pack item events from the items 10010 and 10020 are repeated in the package object 20010. The PrincipalObjectType of this activity is always Item because we want to make clear that these pack item events are touchpoints between the item and the package, and that the package did not cause the event. Also, the ActivityOriginID is the same for the event Pack Item when used in the item process flow and in the package process flow. This prevents erroneous event counts as the distinct ActivityOriginID always gives the correct number of events. |
Link |
CaseID |
ObjectType |
ActivityType |
PrincipalObjectType |
ActivityOriginID |
ActivityStartTimestamp |
100 |
10010 |
Item |
Pick Item |
Item |
10010_pick |
04.04.2022 10:01:02 |
100 |
10010 |
Item |
Pack Item |
Item |
10010_pack |
04.04.2022 10:05:32 |
100 |
10020 |
Item |
Pick Item |
Item |
10020_pick |
04.04.2022 10:03:44 |
100 |
10020 |
Item |
Pack Item |
Item |
10020_pack |
04.04.2022 10:06:21 |
100 |
20010 |
Package |
Create Package |
Package |
20010_create |
04.04.2022 10:04:45 |
100 |
20010 |
Package |
Pack Item |
Item |
10010_pack |
04.04.2022 10:05:32 |
100 |
20010 |
Package |
Pack Item |
Item |
10020_pack |
04.04.2022 10:06:21 |
100 |
20010 |
Package |
Send Package |
Package |
20010_send |
04.04.2022 10:12:23 |
To sum up: for OCPM four new (now obligatory) fields are required:
1.Object Type
2.Principal Object Type
3.Activity Origin ID
4.Link
Given this information the creation of an object-centric event log is straight forward. We will show this with an example, shown below. Imagine a purchase-to-pay process (P2P) including purchase orders, purchase order items, deliveries as well as invoices and payments. Every objects has its own process flow, with interactions / touchpoints to other objects. The touchpoints are marked in blue.
•The purchase order is created, released and closed with the last order-related payment and the last item-related delivery.
•The purchase order item is created and may have price or quantity changes. It has touchpoints with the order when the order is created, with the delivery, when goods are receipt, .
•The delivery document is created, a goods receipt is created upon delivery, and the delivery document is closed.
•The invoice document is received and booked and closed with the last invoice-related payment.
•The payment is scheduled and carried out.
To create the object-centric event log we recommend to follow these steps:
1.Create the event log for every object on its own without touchpoint events at first. Add the ObjectType, the PrincipalObjectType field, and the ActivityOriginID to the event log table. The PrincipalObjectType equals the ObjectType as long as the event is not a touchpoint to another object. It should look like this:
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
1000 |
Purchase Order |
Purchase Order |
Order Created |
1000_orderCreated |
0205.2022 11:55:01 |
02.05.2022 11:58:41 |
1000 |
Purchase Order |
Purchase Order |
Order Released |
1000_orderReleased |
03.05.2022 14:15:08 |
03.05.2022 14:16:58 |
2000 |
Purchase Order |
Purchase Order |
Order Created |
2000_orderCreated |
03.05.2022 14:15:08 |
03.05.2022 14:16:58 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
100010 |
Order Item |
Order Item |
Item Created |
100010_itemCreated |
05.05.2022 14:15:01 |
05.05.2022 14:17:51 |
100010 |
Order Item |
Order Item |
Change Price |
100010_changePrice |
05.05.2022 18:15:08 |
05.05.2022 18:15:18 |
100020 |
Order Item |
Order Item |
Item Created |
100020_itemCreated |
05.05.2022 14:15:01 |
05.05.2022 14:17:51 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
4000101 |
Delivery |
Delivery |
Delivery Doc Created |
4000101_docCreated |
08.05.2022 14:15:01 |
08.05.2022 14:17:51 |
4000101 |
Delivery |
Delivery |
Goods Receipt |
4000101_goodsReceipt |
09.05.2022 18:15:08 |
09.05.2022 18:15:18 |
4000102 |
Delivery |
Delivery |
Delivery Doc Created |
4000102_docCreated |
09.05.2022 14:15:01 |
09.05.2022 14:17:51 |
4000102 |
Delivery |
Delivery |
Goods Receipt |
4000102_goodsReceipt |
10.05.2022 18:15:08 |
10.05.2022 18:15:18 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
5000101 |
Invoice |
Invoice |
Invoice Receipt |
5000101_invReceipt |
09.05.2022 18:16:08 |
09.05.2022 18:16:18 |
5000101 |
Invoice |
Invoice |
Invoice Booked |
5000101_invBooked |
10.05.2022 18:15:08 |
10.05.2022 18:15:18 |
5000102 |
Invoice |
Invoice |
Invoice Receipt |
5000102_invReceipt |
10.05.2022 18:16:08 |
10.05.2022 18:16:18 |
5000102 |
Invoice |
Invoice |
Invoice Booked |
5000102_invBooked |
11.05.2022 18:15:08 |
11.05.2022 18:15:18 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
6000101 |
Payment |
Payment |
Payment Scheduled |
6000101_payScheduled |
10.05.2022 15:16:08 |
10.05.2022 15:16:18 |
6000101 |
Payment |
Payment |
Payment |
6000101_payment |
11.05.2022 16:15:08 |
11.05.2022 16:15:18 |
6000102 |
Payment |
Payment |
Payment Scheduled |
6000102_payScheduled |
11.05.2022 16:16:08 |
11.05.2022 16:16:18 |
6000102 |
Payment |
Payment |
Payment |
6000102_payment |
12.05.2022 17:15:08 |
12.05.2022 17:15:18 |
2.Create the CaseInformation table which contains the CaseID and add the link to every CaseID so that the objects become related to each other. How do you choose the Link level? We recommend taking the former traditional CaseID as the Link. In our P2P example this would be the purchase order ID. The CaseInformation table contains the case context information as you know from the traditional process mining approach.
CaseID |
Link |
CaseDimension1 |
CaseDimension2 |
CaseDimension3 |
CaseDimension4 |
CaseDimension5 |
1000 |
1000 |
... |
... |
... |
... |
... |
2000 |
2000 |
|
|
|
|
|
100010 |
1000 |
|
|
|
|
|
100020 |
1000 |
|
|
|
|
|
4000101 |
1000 |
|
|
|
|
|
4000102 |
1000 |
|
|
|
|
|
5000101 |
1000 |
|
|
|
|
|
5000102 |
1000 |
|
|
|
|
|
6000101 |
1000 |
|
|
|
|
|
6000102 |
1000 |
|
|
|
|
|
| Having created the single objects event logs and the object links, the different logs can already be loaded to the mpmX Template App as one concatenated event log. Since the touchpoint between the objects are still missing, the ProcessAnalyzer would show the five objects without any interaction: |
 |
3.Create the touchpoints between the objects. You have several options here, we recommend you re-use events from other objects to create the interactions.
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
1000 |
Purchase Order |
Delivery |
Goods Receipt |
4000102_goodsReceipt |
10.05.2022 18:15:08 |
10.05.2022 18:15:18 |
1000 |
Purchase Order |
Payment |
Payment |
6000102_payment |
12.05.2022 17:15:08 |
12.05.2022 17:15:18 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
100010 |
Order Item |
Purchase Order |
Order Created |
1000_orderCreated |
0205.2022 11:55:01 |
02.05.2022 11:58:41 |
100010 |
Order Item |
Delivery |
Goods Receipt |
4000101_goodsReceipt |
09.05.2022 18:15:08 |
09.05.2022 18:15:18 |
100020 |
Order Item |
Delivery |
Goods Receipt |
4000102_goodsReceipt |
10.05.2022 18:15:08 |
10.05.2022 18:15:18 |
|
|
|
|
|
|
|
CaseID |
ObjectType |
PrincipalObjectType |
ActivityType |
ActivityOriginID |
ActivityStartTimestamp |
ActivityEndTimestamp |
5000101 |
Invoice |
Payment |
Payment |
6000101_payment |
11.05.2022 16:15:08 |
11.05.2022 16:15:18 |
5000102 |
Invoice |
Payment |
Payment |
6000102_payment |
12.05.2022 17:15:08 |
12.05.2022 17:15:18 |
100020 |
Order Item |
Delivery |
Goods Receipt |
4000102_goodsReceipt |
10.05.2022 18:15:08 |
10.05.2022 18:15:18 |
|
|
|
|
|
|
|
| In general the selection / definition of touchpoints is up to the data engineer and the definition during the process mining project. Different touchpoint definitions may be helpful for different purposes. In case the objects are less kind of an object and more kind of a sub-process it may be feasible to create artificial start and end events for the subprocesses and add them as touchpoints to the parent process. |
| After modeling the touchpoints and concatenating them to the event logs from step 1, the ProcessAnalyzer shows this process flow: |
 |
In the next section How to Configure the mpmX Template App for OCPM (fast track) we will show you in a summed-up guide how to configure the mpmX Template App correctly for OCPM.
