Wie man ein Event Log für OCPM erstellt |
Scroll Previous Topic Top Next Topic More |
Die Hauptunterschiede zwischen dem traditionellen Event-Log und dem objektzentrierten Event-Log sind:
1.Ein Prozess kann mehrere Objekte haben, die ihren eigenen Typ von Case ID mitbringen. Daher ist die Case-ID nicht mehr ein Common-Identifier für die Prozessinstanz, auf die sich alle Events beziehen, sondern der Identifier für das Objekt selbst, das das Event ausgelöst hat. Aus diesem Grund wird die frühere Prozessinstanz nun in dem neuen Feld Link in der Tabelle CaseInformation erfasst, während die Objekt-ID in dem Feld CaseID erfasst wird. Um zu entscheiden, welche CaseID zu welcher Art von Objekt gehört, wird ein neues Feld ObjectType eingeführt.
2.Um die Interaktion von Objekten im ProcessAnalyzer zu sehen, werden einige Schlüsselaktivitäten als Touchpoints verwendet, was bedeutet, dass eine Aktivität, die von einem Objekt ausgeht, auch im Prozessfluss eines anderen Objekts angezeigt wird. Beispiel: Artikel werden in ein Paket verpackt. In diesem Fall könnte die Touchpoint-Aktivität zwischen dem Artikel und dem Paketobjekt "Artikel verpacken" sein, die vom Artikelobjekt ausgeht, aber auch im Paketobjekt verwendet wird, um die Interaktion oder besser gesagt den Touchpoint zwischen den beiden Objekten wiederzugeben. Das neue Feld PrincipalObjectType wurde implementiert, um die Information zu behalten, von welchem Objekt eine Aktivität ursprünglich verursacht wurde.
3.Um die Information zu erhalten, aus welcher Quelle ein Event stammt, ist das Feld ActivityOriginID nun obligatorisch. Durch die Verfolgung dieser Information sind die Zählungen zur Anzahl der Events immer korrekt, wenn sie sich auf diese eindeutige Event-Identifier beziehen. Am wichtigsten ist die korrekte Verwendung der ActivityOriginID, wenn die Aktivitäten als Touchpoints verwendet werden. Hier ist die ActivityOriginID dieselbe ID, wenn sie in verschiedenen Objekten verwendet wird, um Duplikate beim Zählen oder Analysieren von Events zu vermeiden.
Diese Tabelle zeigt die neuen Felder und ihren Zweck. Wir sehen drei verschiedene caseIDs, die von zwei Item-Objekten und einem Package-Objekt stammen. Die drei Objekte sind über das Feld Link verbunden, das in diesem Beispiel die Customer Order ID enthält. Das Feld ObjectType enthält die Information über den Objekttyp für die CaseIDs. Die Felder ActivityType und ActivityStartTimestamp sind wohlbekannt. Schließlich wird der Zweck des PrincipalObjectType und des Feldes ActivityOriginID klar, wenn man sich die blau markierten Zellen genauer ansieht. Die beiden Pack-Item-Events 10010 und 10020 werden im Package-Objekt 20010 wiederholt. Der PrincipalObjectType dieser Aktivität ist immer Item, weil wir deutlich machen wollen, dass diese Pack-Item-Events Touchpoints zwischen dem Item und dem Paket sind, und dass das Paket das Event nicht verursacht hat. Außerdem ist die ActivityOriginID für das Event Pack Item identisch, wenn es im Item-Prozessablauf und im Paket-Prozessablauf verwendet wird. Dies verhindert fehlerhafte Ereigniszählungen, da die eindeutige ActivityOriginID immer die korrekte Anzahl von Events ergibt. |
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 |
Zusammenfassend lässt sich sagen, dass für OCPM vier neue (jetzt obligatorische) Felder erforderlich sind:
1.Object Type
2.Principal Object Type
3.Activity Origin ID
4.Link
Mit diesen Informationen ist die Erstellung eines objektzentrierten Event-Protokolls ein Kinderspiel. Wir zeigen dies anhand eines Beispiels, das im Folgenden dargestellt wird. Stellen Sie sich einen Purchase-to-Pay-Prozess (P2P) vor, der purchase orders, purchase order items, deliveries sowie invoices and payments umfasst. Jedes Objekt hat seinen eigenen Prozessablauf, mit Interaktionen / Touchpoints zu anderen Objekten. Die Touchpoints sind in blau markiert.
•Die Purchase-Order wird mit der letzten Order-related Payment und der letzten Item-related Delivery angelegt, freigegeben und abgeschlossen.
•Die Purchase-Order-Item wird erstellt und kann Preis- oder Mengenänderungen aufweisen. Sie hat Touchpoints mit der Order, wenn die Order erstellt wird, mit der Delivery, beim Wareneingang.
•Der Lieferbeleg wird erstellt, bei Lieferung wird ein Wareneingang erstellt, und der Lieferbeleg wird geschlossen.
•Der Rechnungsbeleg wird empfangen und gebucht und mit der letzten rechnungsbezogenen Payment geschlossen.
•Die Payment wird geplant und durchgeführt.
Zur Erstellung des objektzentrierten Event-Protokolls empfehlen wir die folgenden Schritte:
1.Erstellen Sie das Event-Protokoll für jedes Objekt einzeln, zunächst ohne Touchpoint-Events. Fügen Sie den ObjectType, das Feld PrincipalObjectType und die ActivityOriginID in die Event-Log-Tabelle ein. Der PrincipalObjectType ist gleich dem ObjectType, solange das Event kein Touchpoint zu einem anderen Objekt ist. Die Tabelle sollte wie folgt aussehen:
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.Erstellen Sie die Tabelle CaseInformation, die die CaseID enthält, und fügen Sie die Verknüpfung zu jeder CaseID hinzu, damit die Objekte miteinander in Beziehung stehen. Wie wählen Sie die Link-Level? Wir empfehlen, die frühere traditionelle CaseID als Link zu verwenden. In unserem P2P-Beispiel wäre dies die Purchase Order ID. Die Tabelle CaseInformation enthält die Case-Kontextinformationen, wie Sie sie aus dem traditionellen Process-Mining-Ansatz kennen.
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 |
|
|
|
|
|
Nachdem die Event-Logs der einzelnen Objekte und die Objekt-Links erstellt wurden, können die verschiedenen Logs bereits als ein verkettetes Event-Log in die mpmX Template App geladen werden. Da die Touchpoints zwischen den Objekten noch fehlen, würde der ProcessAnalyzer die fünf Objekte ohne jegliche Interaktion anzeigen: |
3.Erstellen Sie die Touchpoints zwischen den Objekten. Sie haben hier mehrere Möglichkeiten. Wir empfehlen Ihnen, Events von anderen Objekten wiederzuverwenden, um die Interaktionen zu erstellen.
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 |
|
|
|
|
|
|
|
Im Allgemeinen obliegt die Auswahl/Definition von Touchpoints dem Data Engineer und der Definition während des Process-Mining-Projekts. Verschiedene Touchpoint-Definitionen können für unterschiedliche Zwecke hilfreich sein. In Fällen, in denen die Objekte weniger eine Art Objekt und mehr eine Art Subprozess sind, kann es möglich sein, künstliche Start- und End-Events für die Subprozesse zu erstellen und diese als Touchpoints zum übergeordneten Prozess hinzuzufügen. |
Nachdem die Touchpoints modelliert und mit den Event-Protokollen aus Schritt 1 verknüpft wurden, zeigt der ProcessAnalyzer diesen Prozessablauf: |
Im nächsten Abschnitt Wie man die mpmX Template App für OCPM konfiguriert (Schnellkurs) zeigen wir Ihnen in einer zusammenfassenden Anleitung, wie Sie die mpmX Template App korrekt für OCPM konfigurieren.