Skip to main content

Celonis Product Documentation

OCPM Perspective

Description

This section describes the main components of an object centric process mining (OCPM) based perspective. The object-centric process mining perspectives will be the successors of data models to leverage the advantages which are offered by using a holistic model which contains all business objects, event types and the information about how these are related to each other. In the new OCPM environment, you create perspectives by selecting the objects, events and relationships you want to work with. A detailed description of perspectives including their concept and the documentation of the required tasks can be found here. The focus of this document is to describe the components of the perspectives, to describe the differences between OCPM perspectives and (case-centric) data models and to demonstrate with some examples the consequences of using different projections when the perspective was defined.

Benefits of OCPM perspectives

There are numerous benefits to customers when using OCPM based perspectives like simplified transformations, dynamic perspectives, incremental expansion of additional tables and attributes (instead of duplicating existing data models). As discussed very intensely in the scientific community, perspectives also address the common problem of event divergence (when duplicating the header-based events on the item level) or event convergence (when event information is lost because e.g. schedule-line based event information needs to be attached to item-level cases). With object-centric process mining, events are related to objects instead of to a single case, making it possible to fully view complex and interacting processes from any angle.

More information can be found in the Object-centric process mining overview section of the documentation.

Components of OCPM

The following section provides a technical description of what is being automatically generated after the user completed modeling the objects and events as well as the relationships between these. The idea is to provide users who are used to working with the case-centric data model editor the key changes after the introduction of object-centric process mining modeling. The layer in which these tables are defined is hidden to the user. Consequently, the user can only define object and event tables as well as information about how these items are related to each other. The generated tables in the backend can be classified into the following categories:

  • object tables: The object tables list all instances of existing objects. The only required column is the unique object ID column. The objects can be e.g. customers, sales order, sales order items or invoices. Additionally, attribute columns can provide additional information about each object instance (like prices for materials, currencies for customers, addresses for vendors). Please note that the object tables cannot be marked as case tables as before, since there is no case concept in OCPM models anymore. Instead, objects are defined and contribute individually to the perspective of the respective business process.

  • event type tables: This table lists all instances of independent events for one event type. The listed events are identified by an unique ID and a timestamp column. Additional attribute columns are also possible to add additional information about the event instance.

  • relation tables: events can either be connected directly to the respective objects or via mapping tables. The idea behind the relation tables is the fact that events are often not only directly bound to one object (former: one case), but there exist many relations between events and objects. The creation of a delivery item is e.g. highly relevant for the delivery (item) objects (otherwise the item would not exist), but in order to calculate e.g. an open order ratio, a link between the create delivery item event table and the sales order item table is necessary which is provided by the relation table. Since there is very often not a 1:1 relation between sales order items and delivery items given, the mapping table provides the necessary information about how objects and events are connected. There is a distinction between object-to-object relationship tables and object-to-event relationship tables, but the functionality remains the same.

  • change tables: Object changes are stored in so-called change tables which are directly joined to object tables.

Structure of new OCPM perspective

One of the main advantages in Object centric process mining is the fact that events (former activities) are not directly linked to a respective case table. As in real life business processes, events can be bound to several objects and need to be stored independently from objects as long as possible.

It depends on the actual use-case, context and on the business process how events need to be handled and how to calculate KPIs on them. As an example, delivery creation events can either be interesting from the logistics perspective (how many delivery items have been created, what amount of effort was required), especially, if more than one delivery was required for a sales order item. On the other hand, from an order management perspective, the exact number of created deliveries is irrelevant but what counts is just if the order item was completely delivered.

Differences between Data Models and OCPM perspectives

The most important difference between data models and perspectives is the fact that

  • Activity Tables are split up in event type tables: The former activity tables will be split up in event type tables: For each distinct activity name, there will be a new event type table. Therefore, since the former activity column would entail redundant information, the event table will be named after the respective activity name. The new tables will be called event_type tables. The syntax is as follows: e_<namespace>_<EventName>.

  • event_type table joins: Event type tables can be either directly joined to object tables or they can be connected using a relation table. Since each event can be relevant to various objects, relationship tables (also called mapping tables) can be used to store this information about how the event types and the objects are connected.

  • no user access to event-type and relationship tables: In OCPM perspectives, not all tables will be visible and accessible to users. The event-type tables and relationship tables will be hidden from the user and only accessible through the CREATE_EVENTLOG operator. The main idea behind this is the fact that all events only make sense in the context of the lead objects which they are connected to. In case event instances which are not linked to any object will not be accessible and cannot be considered in any event count operation.

The following figures summarize the differences between the two data models. In Fig.1 tables can be classified as activity or case tables and need to be connected via their join relationship. Every table defined in the data model can be accessed via PQL queries directly from the frontend components.

In contrast to data model definitions, object-centric perspectives are defined as a subset of centrally defined objects, events and their relations. The automatically generated tables can be classified in object tables, event tables and relationship tables. Event and relationship tables are hidden tables and cannot be accessed directly with PQL queries in the frontend. Instead, accessing the event tables is only possible by defining a lead object which is the starting point of a user's perspective and by using the CREATE_EVENTLOG operator. By using this operator, there is no limitation of functionalities when accessing the former activity tables: The user can entirely re-build the activity table and use all functionalities and operators which have been available accessing the well known activity tables in data models.

EMS_1_data_model_components.png

Fig.1: EMS 1 data model components including activity tables, case tables and other object tables. All types of tables are configurable and accessible by the users and can be used in PQL statements.

relationshop_and_event_type_tables_OCPM_perspective.png

Fig.2: When defining and using OCPM perspectives, the relationship tables and event type tables will be created in the data model but not directly be accessible with PQL operators except by using the CREATE_EVENTLOG operator.

Examples

In the following example there is a data model defined which consists of a sales order header and item table, a delivery table as well as three event type tables being connected to two relationship tables. The three event types can have sales order header, sales order items or deliveries as lead objects. The examples are intended to demonstrate how the result tables of the CREATE_EVENTLOG operators change when using different methods to create an eventlog from event tables:

  • case-centric data model: Activity table

  • object-centric perspective: Using sales order items as leading object

  • object-centric perspective: Using delivery items as leading object

1. Activity Table in case-centric data models:

The following query (and all wrapping PQL operators) can be used in analyses to access the activity table.

activity_table_in_case-centric_data_model.png

Fig3.: The direct table access of COUNT("_CEL_O2C_ACTIVITIES"."CASE_ID") in the data models returns a row count of 10:

  COUNT(CREATE_EVENTLOG ("o_celonis_Sales_Order_Item", INCLUDE [ "e_celonis_Create_Sales_Order", "e_celonis_Create_Sales_Order_Item", "e_celonis_Create_Delivery" ]))
2. object-centric perspective: Using sales order items as leading object

When using the sales order items as leading objects, the LEAD_OBJECT_ID is generated by the CREATE_EVENTLOG operator from the primary key of the sales order item table.

objective-centric_perspective_using_sales_order_items_as_leading_object.png

The result is very similar to the data model example (in which the step of connecting to lead objects is already done in the transformations):

  • The number of rows does not change and is still 10.

  • The ACTIVITY column is auto generated by using the event type table name.

  • All other column names originate from the event table column names.

The ACTIVITY_TABLE.ACTIVITY_COLUMN statement can be replaced with the CREATE_EVENTLOG statement to get the same results compared to using an activity table.

3. object-centric perspective: Using delivery items as leading object

When using the sales order items as leading objects, the LEAD_OBJECT_ID is generated from the primary key of the delivery item table.

  COUNT(CREATE_EVENTLOG (" o_celonis_Sales_Order_Item ", INCLUDE [ " e_celonis_Create_Sales_Order ", " e_celonis_Create_Sales_Order_Item ", " e_celonis_Create_Delivery " ])."LEAD_OBJECT_ID" ) = 10
object-centric_prespective_using_delivery_items_as_leading_object.png

Since the "create delivery events" are directly connected to the delivery table, the duplication of events (also called divergence) is not necessary anymore. Therefore, the result table has one row missing compared to the other example.

  COUNT(CREATE_EVENTLOG ("o_celonis_Delivery_Item", INCLUDE [ "e_celonis_Create_Sales_Order", "e_celonis_Create_Sales_Order_Item", "e_celonis_Create_Delivery" ])."LEAD_OBJECT_ID" ) = 9