- Release notes
- Before you begin
- Getting started
- Managing access
- Working with process apps
- Creating process apps
- Loading data
- Customizing process apps
- Data transformations
- TemplateOne app template
- Purchase to Pay app template
- Order to Cash app template
- Basic troubleshooting guide
Designing an event log
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.
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 |
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.
purchase_order_type, and an invoice entity might have a payment_due_date.
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”.
