Designing an event log
Introduction
When setting up the transformations for Process Mining, it is important to have a good understanding of the process. The first step is to define the events that occur and the objects on which these events take place.
Define the events
Start by defining the high-value activities. Prioritize adding activities based on how often they occur and how meaningful they are to the end user. Defining the activities should be an iterative process.
The following illustration shows an example of an event log for the Invoices process.
The ideal number of activities to describe a process is between 10 and 20. Although more activities will lead to more possibilities for analysis, it also leads to more process variations, and higher complexity.
| Number of activities | Result |
|---|---|
| <10 | Low analysis complexity, low number of potential improvements. |
| 10-20 | Optimal balance of analysis complexity and potential improvements |
| 20 | High analysis complexity, high number of small improvements. |
Naming conventions
For activity names, the best practice is to use the Verb Noun format, such as Create document. The following table contains some advice on activity naming.
| Activity name | Advice | Best practice |
|---|---|---|
| Order Order | Avoid ambiguous activity names. | Order material |
| Ticket | Avoid singular activity names, state what happened to what. | Create ticket |
| Document cancelled | Avoid passive tense. | Cancel document |
| Approve credit control check on the sales order | Avoid too long activity names | Approve SO credit check |
Define objects
The events take place on one or more objects in the process. Use the set of desired events to determine which objects are needed for a business process. The following table shows an example of a set of events and their corresponding objects.
| Event | Object |
| Create purchase order | Purchase order |
| Approve purchase order | Purchase order |
| Create invoice | Invoice |
| Change payment terms | Invoice |
Each object can have properties that are specific to that object. For example, a purchase order object might have a purchase_order_type, and an invoice object might have a payment_due_date.
Define the event log
The number of objects that are of interest in a process varies depending on the complexity of the process. In some processes only one object may be required, like the ticket in an Incident Management process.
In more complex processes, multiple objects can be of interest. For example, a Purchase-to-Pay process which starts with purchasing a product up to paying an invoice covers a set of events related to multiple objects. To create an event log for such processes, the relations between the objects have to be defined. The following illustration shows an example relationship diagram Purchase-to-Pay objects.
The event log describes the end-to-end process covering the events of all objects combined. Only one object in the process can function as the main object which will be tracked throughout the process. This main object is named the “Case” in the process, identified by its “Case ID”.