第二讲-流程挖掘(Process Mining)学习日志之过程建模与分析

第二讲 过程建模与分析

现今存在大量的过程模型表示法,它们揭示了不同过程模型之间的相关性。一些组织可能会采用不规范的过程模型完成业务和过程的结构化和文档化。然而,BPM成熟度比较高的组织大多采用便于分析和制定操作流程的模型。时至今日,大多数过程模型仍由手工设计完成,缺乏对现有过程数据的严格分析。学习本章内容主要有两个目的。一方面,本章为后续章节将要用到的知识进行初步介绍。例如,在本章中,我们将会介绍许多过程建模方法,并回顾一些对应的分析技术;另一方面,本章我们还会讨论这些传统方法的局限性,正是这些局限性催生了过程挖掘技术。



参考:PROCESS MINING:Discovery,Conformance and Enhancement of Business Processes

2.1 过程模型

从控制流的角度分析过程。假设存在一个活动标签的集合A。过程模型的目的在于决定什么活动需要执行、以何种方式执行。实际活动可以顺序执行,可以选择执行或并发执行,同时相同活动的重复执行也有可能发生。

2.1.1 变迁系统

最基础的过程建模表示法是一个变迁系统,它由状态和变迁组成。图2.1展示了一个含有7个状态的变迁系统,该图建模了1.2节描述的航空索赔请求处理过程。状态用黑色圆圈表示,图中有一个标为s1的初始状态和一个标为s7的终结状态,每个状态都有独立的标签。标签仅仅是一种标识符,没有具体的含义。变迁用弧表示,每个变迁连接两个状态,并以活动名作为标签。多个弧可以使用同一标签,例如,“check ticket”标签在图中就出现了两次。

在这里插入图片描述

定义2.1(变迁系统)
一个变迁系统是一个三元组TS=(S,A,T)。S是状态的集合,A是活动(通常也被称为动作)的集合,T⊆S×A×S是变迁的集合。Sstart⊆S是初始状态的集合(有时也被称为开始状态),Send⊆S是终结状态的集合(有时候也被称为接受状态)。
Sstart和Send集合的定义是隐式的。原则上S可以是无限的,然而在许多实际应用中,状态空间是有限的。此时,这样的变迁系统也被称为有限状态机(Finite-State Machine,FSM)或有限状态自动机。

图2.1中描述的变迁系统可以形式化如下:S={sl,s2,s3,s4,s5,s6,s7},Sstart={s1},Send={s7},A={register request,examine thoroughly,examine casually,check ticket decide,reinitiate request,reject request,pay compensation},T={(s1,register request,s2),(s2,examinecasually,s3),(s2,examine thoroughly,s3),(s2,check ticket,s4),(s3,check ticket,s5),(s4,examine casually,s5),(s4,examine toroughly,s5),(s5,decide,s6),(s6,reinitiate requet,s2),(s6,pay compensation,s7),(s6,reject request,s7)}。

给定一个变迁系统,我们可以对其行为进行推理。变迁由一个初始状态开始,图中任何一条始于初始状态的路径都是一条可能的执行序列。例如在图2.1中,路径(register request,examine casually,check ticket)就是一条从s1开始,至s5结束的执行序列。这个变迁系统有无限个执行序列。一条路径如果以终结状态结束,则为成功结束。如果一条路径进入一个非终结状态,并且没有任何离开该状态的变迁,则称该路径陷入死锁。需要注意的是,成功结束也是一种死锁。变迁系统可能会陷入活锁,即部分变迁仍然是使能的,但是不可能到达终结状态。

所有具有可执行语义的过程模型都可以被映射到变迁系统上。因此,许多为变迁系统设计的模型表示法都可以轻易地被转换为更高层次的表示法,如Petri网、BPMN、UML活动图。举例而言,考虑一个看似简单的问题:“从行为的角度,如何判断两个过程相同”。轨迹等价(trace equivalence)认为两个变迁系统的执行序列相同,则变迁系统等价。更精确的概念如分支互模拟(branchingbisimilarity),还考虑了选择的时刻。只要模型的表达方式是基于可执行语义的,这些等价观念就可以被应用于该表达方式下任意的一对模型。

变迁系统定义虽然简单,但在简洁地描述并发时存在问题。考虑有n个并行活动的情况,也就是说,这n个任务都必须被执行,但是可以以任意顺序被执行。此时有n!种可能的执行序列,变迁系统需要2n种状态和n×2n-1个变迁。这就是著名的状态爆炸问题的一个例子。考虑n=10的情况,可能的执行序列数量为10!=3628800,可到达的状态有210=1024个,变迁的数量有10×210-1=5120个。同一个问题如果用Petri网表达,则更为紧致,只需要10个变迁和10个库所就可以为10个并行任务建模。考虑业务过程中天然存在并行,我们需要更具表达能力的模型,例如需要Petri网来充分表达过程挖掘的结果。

2.1.2 Petri 网

定义2.2(Petri网)
Petri网是一个三元组N=(P,T,F)。其中P是库所的有限集合,T是变迁的有限集合,使得P∩T=Ø。F⊆(P×T)U(T×P)是有向弧的集合,称为流关系(flowrelation)。一个标识Petri网是一个二元对(N,M),其中N=(P,T,F)是一个Petri网,M∈B§是一个定义在P上的多集,代表网上的标识。所有标识Petri网构成的集合用N表示。

图2.2表示的Petri网可以形式化如下:P={start,c1,c2,c3,c4,c5,end},T={a,b,c,d,e,f,h},F={(start,a),(a,c1),(a,c2),(c1,b),(c1,c),(c2,d),(b,c3),(c,c3),(d,c4),(c3,e),(c4,e),(e,c5),(c5,f),(f,c1),(f,c2),(c5,g),(c5,h),(g,end),(h,end)}。

在这里插入图片描述

2.1.3 BPMN

现在,BPMN(Business Process Modeling Notation,即业务流程建模与标注)已经成为使用最广泛的业务过程建模语言之一。BPMN被许多工具提供商支持,并由OMG制定标准。图2.7展示了BPMN模型。
在这里插入图片描述图2.8展示了所有标识符号的一个子集。原子活动被称为任务。与YAWL相同,活动可以嵌套。在介绍YAWL之后,许多BPMN的结构很容易理解。一个显著的不同是,在BPMN中,路由逻辑并非与任务相关联,而是与一个独立的网关相关联。图2.8展示了不同类型的分裂和合并网关:AND、XOR、OR。分裂基于数据条件。一个事件相当于Petri网中的一个库所。然而,Petri网中库所的语义和BPMN中事件的语义并不相同。在BPMN中,没有必要在活动之间加入事件,事件也不允许有多重的输入和输出弧。Start事件含有一个输出弧,intermediate事件含有一个输入和一个输出弧。与YAWL和Petri网不同,事件不能含有多重输入和输出弧,分裂与合并需要通过网关实现。为了建模工作流中的延迟选择(deferred choice)模式,需要使用图2.8展示的基于时间的XOR网关,这说明了事件的用途。在执行任务x之后,存在两个事件间的竞争,其中一个事件可以由超时触发。另一个事件则由外部信息触发。首先发生的事件决定了选择的路径,如果信息在超时前到达,任务z被执行;如果时间在消息到来前用尽,任务y被执行。注意在YAWL中,这个结构可以很容易地通过一个带有两个输出弧的条件进行建模。

在这里插入图片描述
图2.8只是BPMN提供的所有表示法的一个子集。大多数供应商只在他们的产品中支持BPMN的一个子集。此外,用户通常只使用少量的BPMN结构。说明了在实际生活中使用的BPMN模型的子集只含有少于10个不同的符号(虽然BPMN标准为建模人员提供了超过50个不同的图形元素)。出于这个原因,我们在处理过程建模和它们的表示法时,会显得非常实用主义。

2.2 基于模型的过程分析

此处我们会展示如何在分析过程和模型的过程中运用事件数据。然而,本节我们先概述主流的基于模型的分析方法:验证和性能分析。验证与系统或过程的正确性有关,性能分析则关注流转时间、等待时间、资源利用和服务水平。

2.2.1 性能分析

过程和组织的性能可以用不同的方式来定义。典型地,有3种性能维度:时间、成本和质量。对于每个性能维度,可以定义不同的KPI(Key Performance Indicator,关键性能指标)。当考虑时间维度时,可以定义如下性能指标:

  • 生产时间(lead time,通常也被称为流转时间),是案例从被创建到完成所需要的全部时间。在工作流中,这是从源库所i到终结库所o所需的时间。我们测量所有案例的平均生产时间。然而,生产时间的方差同样也很重要。也就是说,所有案例耗时都约为两周的情况,和有的案例只需要几个小时,而其他案例需要超过一个月的情况是很不一样的。服务水平(service level)是指生产时间低于某个阈值的案例的比例,例如所有在两周内完成的案例的比例。
  • 服务时间(service time)是指在某一案例上的实际工作时间。我们可以测量每个活动的服务时间,例如平均用于做决定的时间为35分钟,也可以测量整个案例的服务时间。注意在并发的案例中,总服务时间(即各种活动消耗的时间总和)可能会比生产时间更长。然而,一般情况下,服务时间是生产时间的一小部分(分钟和周的对比)。
  • 等待时间(waiting time)是一个案例等待资源变得可用所需的时间。可以单独为每个活动或对整个案例测量等待时间。一个例子是顾客等待销售代表的时间;另一个例子是病人等待膝盖手术的时间。同样地,我们可能会对平均等待时间或者等待时间的方差感兴趣。也可以在服务水平上关注等待时间。例如,需要膝盖手术的病人,在初步诊断到实施手术,等待时间小于3周的人数比例。
  • 同步时间(synchronization time)是一个活动没有完全使能,需要等待外部触发或者其他并行分支所需要的时间。与等待时间不同,该活动并没有完全使能。也就是说,案例在等待同步而不是资源。例如,考虑图2.2所示的工作流网在标识[c2,c3]时的情况。活动e需要等待check ticket完成。条件c4和c3的托肯到达时间的差异即为同步时间。

性能指标可以在成本维度上定义。可以采用不同的成本模型,例如,ABC(Activity BasedCosting,基于活动的成本)、时间驱动ABC和RCA(Resource Consumption Accounting,资源消耗结算)。执行一项活动的成本可以是固定的,也可以依赖于使用资源的类型、利用率和活动持续时间。资源成本可能依赖于资源的利用率。一个在大多数过程中使用的关键性能指标是指定时期内的平均资源利用率,例如一个医院的手术间在过去两个月中有85%的时间在使用中。对各种成本模型的详细讨论超出了本书的范围。

质量维度通常关注于提供给客户的产品或服务。与成本相同,可以通过不同的方式来度量该指标。一个例子是通过问卷调查客户满意程度;另一个例子是每个样例的平均投诉数量和产品缺欠数量。

验证关注过程建模的逻辑正确性,而性能分析则关注从时间、成本和质量的角度改进过程。运营管理学科,发展出了许多相关分析技术。一些技术通过给定的特殊性能指标来优化模型,例如,可以使用整数规划和马尔可夫决策问题来寻找优化策略。对于本章中描述的过程模型,使用仿真、排队模型或马尔可夫模型来分析“如果……会怎么样”问题是最恰当的。分析模型通常需要做出许多假设,并且只能回答特定的问题。因此,我们需要求助于仿真技术。许多BPM工具提供了仿真功能。

2.2.2 基于模型分析的局限

验证和性能分析严重依赖于模型的质量。当模型和现实相似度不高时,基于模型的分析起不到太大的作用。例如,过程模型可能内部稳定并且符合所有需要的性质,然而如果模型描述了现实的一个理想版本,那么这个模型就是无用的,因为在现实中,所有类型的偏差都有可能发生。对于仿真模型也有相似的评论。模型可能预测一个显著的提升,然而实际并非如此,因为模型基于错误的假设。所有这些问题都源于手工模型和现实之间缺乏一致。过程挖掘的目的是,通过在过程模型和关于过程的低层次事件数据之间建立直接联系,从而解决手工模型和现实模型失配问题。此外,本书中讨论的发现技术允许通过不同的角度和不同的抽象层次来分析同一个现实问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值