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 entities 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.

Below is 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. See the table below for 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 entities

The events take place on one or more entities in the process. Use the set of desired events to determine which entities are needed for a business process. Below is an example of a set of events and their corresponding entities.

Each entity can have properties that are specific to that entity. For example, a purchase order entity might have a purchase_order_type, and an invoice entity might have a payment_due_date.

Define the event log

The number of entities that are of interest in a process varies depending on the complexity of the process. In some processes only one entity may be required, like the ticket in an Incident Management process.

In more complex processes, multiple entities 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 entities. To create an event log for such processes, the relations between the entities have to be defined. See the illustration below for an example relationship diagram Purchase-to-Pay entities.

The event log describes the end-to-end process covering the events of all entities combined. Only one entity in the process can function as the main entity which will be tracked throughout the process. This main entity is named the “Case” in the process, identified by its “Case ID”.