Designing an event log

简介

为 Process Mining 设置转换时，充分了解流程非常重要。 第一步是定义发生的事件以及发生这些事件的实体。

Define the events

首先定义高价值活动。根据添加活动的发生频率以及对最终用户的意义，确定添加活动的优先级。定义活动应该是一个迭代过程。

以下是“发票”流程的事件日志示例。

描述流程的理想活动数量为 10 到 20 个。 尽管活动越多，分析的可能性就越大，但也会导致流程变体越多，复杂性也越高。

活动数量	结果
<10	分析复杂性低，潜在改进数量少。
10-20	分析复杂性和潜在改进之间的最佳平衡
20	分析复杂性高，需要进行大量细微改进。

命名约定

对于活动名称，最佳做法是使用动词名词格式，例如“创建文档”。 有关活动命名的一些建议，请参见下表。

活动名称	建议	最佳实践
订单订单	避免使用有歧义的活动名称。	订购材料
工单	避免使用怪异的活动名称，请说明活动内容。	创建工单
文档已取消	避免使用被动时态。	取消文档
批准销售订单的信用控制检查	避免使用过长的活动名称	批准 SO 信用检查

Define entities

事件在流程中的一个或多个实体上发生。 使用所需事件集来确定业务流程需要哪些实体。 以下是一组事件及其相应实体的示例。

每个实体都可以具有特定于该实体的属性。 例如，采购订单实体可能具有purchase_order_type ，发票实体可能具有payment_due_date 。

Define the event log

流程中相关实体的数量因流程的复杂性而异。 在某些流程中，可能只需要一个实体，例如事件管理流程中的工单。

在更复杂的流程中，可能需要关注多个实体。 例如，从购买产品到支付发票的“采购到付款”流程涵盖与多个实体相关的一组事件。 要为此类流程创建事件日志，必须定义实体之间的关系。 有关“购买到付款”实体的关系图示例，请参见下图。

事件日志描述了涵盖所有组合实体事件的端到端流程。 流程中只有一个实体可以用作将在整个流程中进行跟踪的主要实体。 此主要实体在流程中称为“案例”，由其“案例 ID”标识。