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