接上文，该案例已对数据集做了如下分析和操作：
1、整体数据统计和噪声消除
2、对业务流程和数据的对应情况做了整理和分析
3、进行了流程发现，对不同的item category构建了基于真实数据的BPMN模型
接下来，让我们看看如何使用流程挖掘技术对数据进行深入的价值发现。
首先，该案例对此数据集进行了基于规则的一致性检查，
一致性检查旨在分析观察到的和理想的过程行为。例如，后者可以表示为规范的商业模式或由规则定义。某种程度上来看，规则也可以表达业务规则，比如满足四眼原则，或与给定流程更相关的特定匹配行为。
与其他一致性检查方法相比，规则检查提供对流程一致性的有用且直接的见解。一般来说存在五种类型的规则：
（i）排序规则
（ii）基数规则
（iii）排他性规则
（iv）响应规则和
（v）优先规则
规则简单理解就是一个流程case中event之间的相互关系，比如响应规则定义了每当某些event出现在案例中时，最终必须在同一case中存在另一些event。类似地，优先级规则定义某些event必须在指定event发生之前发生在同一case中。通过计算每个规则的违反和满足情况，可以衡量流程的一致性。
通过优先规则检查，得出如下结果：
图片
我们逐个解读：
首先我们看2 way match 和 consignment的流程一致性情况，这两种情况是最不违规的。由于没有为寄售采购订单记录发票，因此无法从控制流派生任何业务规则来进行合规性分析。此外，对于2 way match只能派生一条规则。在观察到的案例中不存在违规情况。
其次检查在3-way match,Invoice after GR这个类型的流程，在这个类型的流程中，GR这个活动一定要在Invoice之前，这是极为关键的。但通过一致性检查，我们发现：
1、在EC Order类型中，约有7%的订单违反了这一规则。此外，在三种情况下，并非所有记录的发票都已结清，约有6%的发票在未先记录货物的情况下已付款。在没有收到货物的情况下支付发票可能暗示存在欺诈行为。这些项目的平均金额为130322.85欧元（总计100万欧元左右）。最多的关联部门（13例）是“Marketing”。
2、标准和框架Order类型中，约有4.5%的情况下，发票在记录货物之前都已结清。在记录货物之前记录发票的频率为5%。
其中第一种情况的主要和两个供应商相关，即vendorID 0404和vendorID 0236。在423起违规流程中，第一家供应商参与了89起案件，第二家供应商参与了82起案件。此外，大多数案例属于“标准”项目类型（281例），其次是“服务”类型（124例）。最后，大约46%的违规案例来源为“销售”部门。
图片
对于第二种不合规情况，在所有受影响的case中，相同的供应商（vendorID 0404:120次，vendorID 0236:88次，共533次）参与最多。约44%的案件属于“销售”。
最后我们再来看3-way match,Invoice before GR这个类型的流程一致性检查的情况：
这种类型的流程更加灵活，可以在收到货物之前记录invoice。但是，这种情况下，仅可以处理发票，但不能进行支付操作，因此必须设置冻结支付set payment block,直至GR之后方可remove payment block。
1、在EC Order类型中，如表4所述，所有具有“remove payment block”活动的case都缺少之前的“set payment block”活动。在任何情况下都不包含此活动。虽然所有采购订单都是“standard”类型，但几乎50%的案例属于“Enterprise Service”支出领域。由于此活动未记录一次，因此可能是流程设计缺失，或本身数据质量问题。在大约2.4%的情况下，发票已在未收到发票的情况下结清之前的货物,并且并未说明其原因，显示明显的例外流程。
2、Standard Order大多数情况下的日志都属于此类型。和EC Order的情况类似，“set payment block”不会出现在99.98%包含“remove payment block”的所有情况中，提示需要调研流程设计或数据质量。另外，有2.83%的案例违反了在“clear invocie”之前“record goods receipt”。其中，八家供应商参与这些案例的次数超过了平均10次。中位数分析显示，每个供应商只参与两次。其中约三分之一属于“销售”领域，22%属于“包装”，21%属于“贸易和终端产品”。这些支出领域合计约占受影响订单高达累计订单价值的30%。
至此，通过本案例中基于规则的流程一致性检查，发现了可能的流程缺失，或数据缺失，以及100万欧元左右的潜在欺诈，以及数千起不合规的流程。
再下一篇，我们将继续拆解如何此案例进一步对流程进行的性能分析，记得关注。
