Designing an event log

简介

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

Define the events

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

下图显示了“发票”流程的事件日志示例。

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

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

命名约定

对于活动名称，最佳实践是使用动词名称格式，例如创建文档。 下表包含有关活动命名的一些建议。

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

定义对象

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

事件	对象
创建采购订单	采购订单
批准采购订单	采购订单
创建发票	发票
更改付款条款	发票

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

Define the event log

流程中感兴趣对象的数量因流程的复杂性而异。 在某些流程中，可能只需要一个对象，例如事件管理流程中的工单。

在更复杂的流程中，可能会对多个对象感兴趣。 例如，从采购产品到支付发票的“采购到付款”流程涵盖与多个对象相关的一组事件。 要为此类流程创建事件日志，必须定义对象之间的关系。 下图显示了一个“购买到付款”对象的示例关系图。

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