BPMN建模方法论

Posted 2023-03-24

参考技术A BPMN（业务流程管理）是一种用于捕获、设计、执行、记录、测量、监控和控制自动化以及非自动化流程，以满足公司的目标和业务策略的系统方法。

通过BPMN，流程可以与业务战略保持一致，藉由业务部门内部甚至超越公司边界的流程优化，有助于提高公司的运转效率。

BPMN在国内的应用很广泛，但很多企业花费大价钱购买了第三方的流程平台，却没有得到相应的收益；我认为其根本原因还是在于对BPMN本身的理解不足——它远没有看上去那么简单，仅仅是BPMN2.0版本规范文档就已经达到了500页。

因此，在我看来，要想顺利的实施BPMN，一个对它有透彻理解的设计者是必不可少的；同时，设计者还需要兼具业务思维、管理思维，和一定的技术思维。

本文以一个物业维修流程为例，目的在于介绍一个系统的BPMN建模方法，为刚刚踏入这个领域的人提供一个方向和选择。

这是一个典型的物业维修流程，这个流程提供的信息量很少，以至于如果我们要仅仅基于此去设计一个完善的BPMN流程是几乎不可能的，但是即便是最专业的物业管理师，这也是他们仅能提供的流程图了.

为了达到我们的目标，我们需要先建立一个战略层面上的流程，它可能很粗糙，但是它的目的并不是在初期就呈现一个完整详细的视图.

它的作用可能有如下几点:

1.澄清什么是，和什么不是这个流程的一部分

2.为流程确定资源和分配责任

3.确定关键绩效指标并明确其特征

4.在对流程着手优化前先对其进行一个大致的回顾

体积：战略流程模型应当尽可能小，流元素最好不要超过10个，如果一个流程横跨几张纸的话，是没人能理解得了的.

语法：尽可能正确，但是在必要时可以不那么严谨

想要对一个流程进行初步建模，往往比想象的要难得多，有时手头有充足的资料和标准的操作流程可以用，那会好些，但大多数时候都不得不去与客户深入交流.

当产品去和客户开会沟通时，我能很容易的想象到下面的景象——当你只画了一个圈两个矩形：

客户参会人员：

我们的维修流程并不总是这样从业主填写维修单开始的，业主也可能是电话报修

如果维修的工程量比较大的话，我们还得先提出方案，然后交给公司领导审批

如果过了保修期的话，那我们还要收钱的

业主如果是预约的话，我们还得根据他预约时间安排工作

并不一定是业主报修，也可能是在物业巡检的时候发现问题，由巡检员报修

..........

..........

..........

如果没有一个狠人来主持会议的话，产品会很容易迷失方向，也会导致客户的参会人员对你的方案失去兴趣，更差的情况是，其他人糊里糊涂地对一个错误的模型达成了一致.

所以主持会议的人，需要在开始的时候先声明好：所有的流程模型都是不完整的，但是它依然有一些作用.

在一开始找出每一种可能性是不可能的，在这次会议开始前，就应当告诉客户，这第一次的迭代目标是什么.

1.我们要记录流程从开始到结束的过程

2.我们最多只记录这个流程的N个步骤

3.我们只记录这个流程的标准形式

如果会议期间仍有人想跳出圈定的范围，应当立刻阻止.

下面回到正题——物业维修流程.

基于上面的传统流程图，我们可以得到以下信息：

1.这个流程往往是由业主有维修需求引起

2.发起人填写一个维修单，发单部门（也就是行政部）将维修单提交到客户服务中心，客户服务中心的经办人填写工程单汇总表，然后把维修任务下发到维保部门，主任分配工作给维修工，维修工执行任务，并会同发单部门验收以确认维修完成.

3.当维修完成的时候，这个流程也就结束了.

基于关键信息，我们可以构建如下的流程图，这里我们出于BPM原则，要先把结束事件放在需求方的泳道上.

尽管这个模型有很多问题，但是这个阶段我们要确保客户能毫不费力的理解它，因此做到这样就可以了.

接下来，我们可以开始逐步的纠正这个错误的模型了.

首先是泳池和泳道，根据BPMN的规范要求，每个流程都应当有一个最高的统筹者（这个请自行查阅BPMN规范），负责协调流程中的参与人和系统，但这个流程不是由流程引擎控制的（它是由发起人控制的），因此它目前不存在这么一个协调者，当业主报修时候，无法路由到下一个活动 (如果把分配到下一节点的受让人当成一种路由方式的话，那么这时候其实是流程引擎在当协调者).因此这边应该建模成消息流，另外，应当把业主分配到另一个池里.

我们建模越详细，发现的问题也随之增加，比如，业主如果中途不想维修了，在这个模型下流程是无法"正常"地结束的 ，如果需要满足这个业务需求又不希望通过技术手段生硬的结束，那么就会需要用到边界事件；另外，如果维修工需要用到一些材料的话，他该怎么办，是否需要申请，又向谁申请？

对于战略模型，为了尽可能简单，通常不会使用多个池，除非是像上面这种业主是独立于物业公司之外的情况，可是由于我们的关注点依然应当集中在物业公司的内部流程上，因此接下来讲业主的池进行折叠.

任务经常出现在战略流程模型中，但是子流程很少出现. 在战略流程模型中不会去指定任务的类型，也不使用除了循环之外的标记，因为循环相对来说很容易理解.

子流程应该细化流程模型，在维修流程模型中，我们定义的这些任务，背后可能并不简单，他们可能对应着非常复杂的操作。 但是对于发单人填写登记表这类任务，从我们得到的信息来看，只管填就行了，所以我们就还是把它们当做任务. 基于这些考虑，我们可以得到下面的模型.

我们只是对于可能存在复杂逻辑的任务做一个子任务标记，就足够了.

上面给出的模型，只是基于最常见的情况，对于一些确实有必要做分支的情况，我们就需要用网关来对这类情况进行建模，但一般来说不会在战略流程模型中引入网关.

在战略流程模型中使用的事件类型是有限制的:

空类型可以用在开始，中间，结束事件上，中间事件可以记录流程执行过程中的某个状态，客户也很容易理解.

消息类型和定时类型可以被允许作为开始事件和中间事件使用，因为它们的符号一看就能看懂，很容易理解.

至此战略流程模型就可以结束了。

在操作流程模型中，就可以开始呈现出流程关于人和技术的细节了，这里会涉及到一些问题：

1.对于流程设计者：工作是如何完成的?

2.流程开发人员：需要通过流程引擎来实现什么功能？

3.流程参与人员：该怎么完成自己的工作？

要调和这三个角色并不简单，而这也正是操作流程模型需要做的事情，如果很好的回答了这三个问题，那么就可以得到以下好处：

1.操作流程模型的逻辑，在实际操作和技术实现上是一致的.

2.缩小了业务和技术之间的理解沟通的沟壑，双方以流程模型作为共同语言.

3.藉由流程引擎实现的流程，更易于观测.

在这个层面上的模型，就不像战略流程模型能容忍一些语法上的错误了，我们必须按照规范来进行建模.

除了规范之外，必须实现的还有精确性，因为客户需要根据这个流程模型安排工作，同时，我们也应当尽可能的不让这个流程显得过于复杂，毕竟流程参与者关注的是他们的工作本身而不是BPM，流程对于他们只是一种达到目的的手段.

之前有说到，操作流程模型应当足够精确但又不过于复杂，这听起来可能很矛盾. 为此，我们先作一张表格，来看看操作流程模型在三个角色中的视图是怎样的. 流程参与者只需要关注自己需要怎么做，以及什么时候需要等待其他人完成什么，这样就不会被其他人所做的细节分散掉注意力.

操作层面的流程模型的核心思想，在于区分编排和协作，如之前所讲，每个流程参与者都有自己的一个池.

把流程引擎作为一个单独的池，可以让流程开发者更好的关注它.

流程设计者的角色在这边非常重要，需要非常懂BPMN，并且能够从不同参与者的视角对流程进行建模.

设计者的工序可能如下：

1.审查战略流程模型

2.分割泳道到单独的池

3.在不同参与者的视角下进行建模

4.为技术层面的建模做准备

5.进行技术层面的建模，不一定可执行，目的在于细化模型

6.加上必要的注释

当然这也只是一种经验方法而已，你也可以直接在技术层面开始分析和建模，自下而上.

继续我们的物业维修流程例子，为了简化对于每个流程参与者的模型复杂性，我们需要将物业公司下面的三个参与者泳道都分割到单独的池中，同时，我们也要解决一些显而易见的逻辑上的错误，比如:

1.验收没有联合业主一起

2.省略了仓管这一参与者

3.省略了客服专员的每周汇总和进度督促.

4.业主报修的时候更多是电话申报

这里最大的难点在于，由于存在代发起的情况，我们很难把业主的池和接线员的池完全隔离开，虽然在流程引擎的层面上可以用两个流程变量来解决问题（发起人，拥有人），但是在模型展示的层面上这种办法是没法很好的表达出意思的，而且也会增加开发的工作量，因此我们可以采用多个开始事件的形式，来对这一情况进行建模.

这就是将流程参与者分割到单独的池后的模型图，这里依然存在一些问题，比如我们还没有对维修项目做分级，验收未通过的话怎么调整参数等等，但这一步我们也只是澄清各个流程参与者之间的关系，没必要过于深究.

从这一步开始，往往就需要与流程参与人员进行更详细的交流了.

从业主开始，我们可以看到业主相关的参与者有接线员，行政部门和机电维修部门，此时我们可以把这两者的池进行折叠.

根据我们已知的业务场景：

如果业主申报的维修项目是有偿服务，需要由客服与其进行再次确认

如果涉及付费服务，业主需要有一个付款的操作

在更深一步的考虑之后，我们发现业主池还会涉及到客服部门，最终我们得到如下模型.

行政部门的流程比较简单，涉及到的其他池有业主和客户服务中心:

客户服务中心这边应当注意，在客户给出的传统流程图中，有提到定时性质的统计和催促的任务，这种情况我们应当将它作为另一个单独的流程模型，与当前的维修流程模型区分开来.

通过调研可以发现，客户服务中心这边往往在完成物业服务之后还会有一次回访调研的过程，因此在维修结束，确认业主验收完成后，我们也应当加上回访的过程，但是回访并不存在于某个特定的流程中，因此我们在此处暂时省略，后续作为一个独立的流程进行建模.

另外，客户服务中心还需要在派单之前与业主进行事前沟通，需要有一定的规则来给维修事项进行分级：

1.是小修，中修，还是大修？

2.是否需要收费？

经过调研我们可以了解到:

三种类型的维修都有可能会需要收费

中修和大修往往还需要经过额外的审批流程才能继续.

我把维修项目评估任务放在了这里，是因为客服联系业主之前需要知道维修的价格以及其他情况.

机电维修部这边应当考虑以下因素：

主管分配工作的细节

1.是否应当记录返工次数？

2.区分不同级别的维修项目

主管分配工作这个任务的前置条件是收到维修需求，确切的说，是收到由客户服务中心填写的工程单汇总表，当前表中已存在的属性可能有客户的姓名，维修地址，联系电话，维修内容，预约时间等.

主管此时需要根据已知的情况，判断当前的维修方案是否需要走额外的审批流程， 而这个流程，应当与当前的维修流程独立开来. 至于这个额外的流程有着怎么样的过程，目前我无法得知，因此依然用一个子流程来代替.

仓管这边需要考虑验收没有通过的情况下，流程如何进行？ 这里的验收事实上应当是物料仓库的验收，与维修流程无关，但是客户往往无法清晰的表达出来这层意思. 因此这边应当暂时省略验收这个步骤， 作为一个独立的物料仓检流程在下一步的时候进行建模.

最后是接线员，接线员的流程比较简单，接到电话报修后填写维修单就可以:

之前都是讲的人与人之间的流程，从这步开始引入流程引擎，原因之前也提及过，开发者需要知道他们要用流程引擎来做些什么事情，因此这个步骤也会添加包括技术实现上的更多细节，比如对于业主是否已经付款的校验.，但第一版的技术流程模型 不一定是可执行的 .

第一版的技术流程模型如下：

再接下来的设计，就需要考虑更多外部因素了，如果我们发现维修流程中，某个泳道的流程能够被其他的流程模型复用，我们就需要将他们抽离并单独部署，如果我们满足于将这个庞大的维修流程进行单独部署，那我们可能还需要再做更多的修改，尤其是事件类型上（消息事件的用法在这里是违反BPMN规范的，如果部署在同一个流程定义中的话，更适合的是条件事件），情况不同，我们后续的设计和实现也会非常不一样.

对于当前这个维修流程，我更倾向于将所有流程都分开设计和实现，主要理由有如下几点：

1.一个庞大的模型，它的版本迁移过程往往非常复杂，如果将它进行恰当的分解，那么我们只需要对发生了变动的部分进行迁移即可，可以有效的降低迁移成本

2.对于开发者来说，庞大的或者过于复杂的模型会导致理解和开发成本迅速上升，而且一个单体模型，几乎只能由一个开发者来负责，不适合多人协作，而分解的手段可以将一个单体复杂模型分解成多个简单、可独立开发的流程模型，可以提升开发效率和降低理解难度.

3.对于企业工作流来说，多个工作流之间经常会存在共通的部分，就像这里的物业服务的回访流程，将这些公共部分剥离出来，长远来看，可以提升模型的复用率，从而提升开发效率.

但是这种方案的缺点也是显而易见的，主要有:

1.分解到什么程度并不那么容易把握，虽然按照经验来说往往是分解到每一个流程参与者，但在有些时候也可以将一些任务比较简单的参与者流程进行合并.

2.为了实现流程实例之间的通信，往往会存在较多的消息/信号事件或者调用活动，要求开发者对BPMN中的事件有足够的了解

3.流程走向的观测可能会比较繁琐，因为需要在多个流程实例之间来回切换观察

下面给出第一版的技术流程实现，它依然还有很多值得改进的地方，比如支付流程的分离和异常处理，维修主管分配任务的自动化规则，接线员流程的规则化（使用规则任务来根据输入参数判断该发送什么类型的消息事件，可能是代填维修单，也可能是代填其他的表单），但出于成本考虑我们不可能就第一版的实现去无止尽的细化：

https://github.com/LLLLimbo/camunda-demo.git 

初学者的BPMN教程 - BPMN for Beginners

• BPMN事件
• 发现BPMN事件
• 所有页面

第1页，共3页

本教程介绍了BPMN 2.0的基本功能。BPMN代表业务流程建模符号，是OMG维护的公共标准。它描述了业务流程图分析和业务用户可用于为业务流程建模并支持流程交互，异常处理，薪酬语义等的业务友好型流程图。

BPMN它被商业和开源BPMS工具供应商广泛接受。它具有很强的适应性，可用于捕捉从抽象过程概述到详细过程流程到实施准备过程的所有内容。BPMN的一个主要价值主张除了是图表标准外，还有图表背后的精确语义。形状，符号（也称为标记），边界，BPMN图元素的位置以及它们的属性具有明确定义的含义，并且必须由所有工具以相同的方式进行解释。

尽管BPMN 1.1全面地处理了过程建模符号，但它实质上缺少解决交换格式（用于图交换）的问题。这导致实施供应商采用不同的标准（BPEL，XPDL或JBPM的JPDL）来存储BPMN流程模型，这不仅导致跨工具的可移植性损失，而且使各个利益相关者之间的沟通变得困难。
这里我们将总结这些年出现的不同标准的简短描述：

JPDL：

• 分析师和开发人员为导向。
• 与jBPM和Java紧密相连。
• 允许定制流程路由逻辑和一大组内置节点。
• 直观的XML语言。

BPEL：

• 基于文本的（XML）业务流程建模语言，包括精确的执行语义。
• 用于编排Web服务。
• 不包含表示流程图的图形方面的元素。

XPDL：

• 旨在交换流程定义，包括图形和工作流业务流程的语义。
• 顾名思义，它包含用于保存图形信息的元素，例如节点的X和Y位置。
• 包含以及可用于运行流程的可执行方面。

BPMN的愿景是为符号，元模型和交换制定单一规范。此外，BPMN 2.0已扩展为包括流程模型的编排和编排。

业务流程图是由描述业务流程的一组图形元素组成的简单图。BPD有四个主要元素：

• 流对象：表示业务流程图的核心要素。
• 连接对象：用于连接BPMN核心对象
• 泳道：是在流程图上组织活动和责任的机制。
• 工件：允许流程设计者扩展基本BPMN表示法，以在流程图中包含有关流程的附加信息

正如我们所说的，流对象是表示业务流程图（BPD）的核心元素的形状，其中包括：

• 活动：是在过程中执行的任何工作。
• 事件：在业务过程中发生的任何事情。
• 网关：用于控制流程的流程。

下图描述了一个包含开始事件，活动（任务），一些网关和结束事件的示例流程：

BPMN和传统流程图之间最大的区别在于对事件的支持。事件是发生了什么事情的信号，BPMN让你说出过程应该如何响应。
这里重要的定义！
事件可以发生在流程的开始（开始事件）或结束（结束事件）或中间（中间）。此外，一些活动可能发生在活动的边界上。这表明事件可以中断活动，并将序列流从“正常”流转移到另一个流。

下图描述了订购某些产品的过程，其中包括a开始事件（消息事件），中间错误事件，边界计时器事件和两个结束事件。

事件可以捕获（当接收触发器被触发时）或抛出（向触发器发送触发器）类型。

开始事件始终是捕获类型，结束事件始终是抛出类型。中间事件可以是throw或catch类型。BPMN 2.0中有各种各样的事件。事件类型列出如下：

	消息事件	发送或接收消息。
	计时器事件	总是捕捉类型并用于表示等待特定时间条件评估为真。
	信号事件	用于发布和订阅信号。
	错误事件	用于异常处理，它们只能在过程结束时发生。
	终止事件	用于终止进程，并且只能在进程结束时发生。
	有条件的事件	用于基于规则的触发器。
	升级事件	在BPMN 2.0中新引入了处理升级条件。
	补偿事件	介绍到处理过程中的赔偿。

根据事件的组合，触发事件的阶段（开始，中间，边界）以及事件是否中断活动，事件可以用不同的图形符号组合表示。

消息事件

消息事件是引用已命名消息的事件。消息具有名称和有效负载，并且始终指向单个接收者。
消息的图形表示可能因消息发送/接收的阶段而异。

开始：消息从参与者到达并触发流程的开始。

中间事件：消息从参与者到达并触发事件。这会导致进程继续等待消息，或者更改异常处理流。当用于“捕捉”消息时，事件标记将被填充。当用于“扔”信息时，事件标记将被填充。

中级边界事件：消息从参与者到达并触发事件。如果消息事件附加到Activity的边界，它将在触发时将Normal Flow改变为Exception Flow。
对于中断与之相关的活动的消息事件，事件的边界是固定的。
对于不中断附加到其中的活动的消息事件，该事件的边界是虚线的。

结束：这种类型的结束表示在过程结束时将消息发送给参与者。

计时器事件

定时器事件是由定义的定时器触发的事件。它们可以用作开始事件，中间事件或边界事件。

开始：可以设置特定的时间日期或特定的周期（例如，每天早上9点），以触发流程的开始。

中间事件：可以设置特定的时间日期或特定周期（例如，每周二上午9点），以触发事件。如果在主要流程中使用，则它用作延迟机制。如果用于异常处理，它将把正常流程改变为异常流程。

中间边界：可以设置特定的时间日期或特定周期（例如，每天早上9点），以触发事件。如果一个定时器事件附加到一个Activity的边界上，它将在正常流程被触发时变成一个异常流程。

对于中断其所附的活动的计时器事件，事件的边界是固定的。对于不中断附加到其中的活动的计时器事件，该事件的边界是虚线的。

信号事件

这种类型的事件用于发送或接收信号。信号用于过程组件内的一般通信。一个BPMN信号与任何可能有兴趣注意并随后作出反应的人都会发射到天空中的信号耀斑类似。因此，有一个信号源，但没有具体的预期目标。这与具有特定源和特定目标（可以是实体或抽象角色）的BPMN消息不同。

开始：信号到达，已从另一个进程广播并触发进程启动。请注意，信号不是消息，它具有消息的特定目标。

中间事件：如果事件是正常流程的一部分，则此类中间事件可以发送或接收信号。信号事件可能被中间捕获信号事件捕获。

中间边界：当附加到活动边界时，信号在被触发时将正常流程改变为异常流程。Signal事件与Error事件的不同之处在于Signal为中断活动（例如成功完成另一个活动）定义了一个更一般的非错误条件，并且其范围比错误事件的范围更大。
对于中断与之相关的活动的信号事件，事件的边界是固定的。对于不中断附加到其中的活动的信号事件，该事件的边界是虚线的。

错误：这种类型的结束表示当到达结束时将会广播信号

错误事件

开始：错误开始事件只允许触发一个在线事件子过程。鉴于错误的本质，具有错误触发器的事件子过程将始终中断其包含的过程。

中间边界：中间错误捕获事件只能附加到活动的边界。请注意，错误事件始终中断与其相关的活动，即没有此事件的非中断版本。事件的边界因此总是稳固的。

结束：这种类型的结束表示应该生成一个命名的错误。错误将由具有相同ErrorCode的错误中间事件捕获，或者在最近的封闭父活动（分层）边界上没有ErrorCode。
    

补偿事件

补偿是“撤销”行为效果的手段。例如，假设您已经在流程开始时预订了一场演出门票，那么补偿可能会取消预订。

开始：补偿开始事件只允许触发在线补偿事件子过程。发生补偿时触发此类事件。此事件不会中断流程，因为流程必须在触发此事件之前完成。

中级：用于补偿处理 - 既激活又执行补偿。
在正常流程中使用时，此中间事件表示需要补偿。因此，它用于“抛出”补偿事件，并且必须填写事件标记。如果事件确定一项活动，那么这是活动（而不是其他）将被补偿。否则，薪酬将广播给在流程实例中完成的所有活动，包括顶级流程和所有子流程。按照完成活动的相反顺序，每项已完成的活动都将得到补偿。要获得补偿，活动必须在其边界附加补偿中间事件。

边界：补偿边界事件与其他边界事件有不同的激活策略。其他边界事件，例如信号边界事件，当它们所连接的活动开始时被激活。补偿边界在附加活动成功完成时激活。此时，创建相应的补偿事件订阅。

当附加到Activity的边界时，此事件用于“捕获”补偿事件，因此事件标记必须未填充。该活动将通过针对该活动提出的报酬来触发。当事件被触发时，与事件相关的补偿活动将被执行。
请注意，其他事件的中断和非中断方面不适用于补偿事件。补偿只能在他们所附的活动完成后触发。
因此他们不能中断活动。事件的边界总是稳固的。

结束：这种类型的结束表示补偿是必要的。如果一项活动得到确定，那么这就是将要得到补偿的活动。否则，在流程内完成的所有活动（从顶级流程开始并包括所有子流程）都将按照相反的顺序进行补偿。要获得补偿，活动必须在其边界附加补偿中间事件。

有条件的事件

真实世界的业务流程往往体现出复杂的决策。条件事件因此可用于过程中包含的基于规则的触发器。

开始：当“标准普尔500自开盘后变化超过10％”或“温度超过300°C”等规则条件变为真时，触发此类事件。事件的ConditionExpression必须变为false，然后才能再次触发Event。

中级：这种类型的事件在规则条件变为真时触发。

边界：这种类型的事件在规则条件变为真时触发。条件是一种表达。如果条件事件附加到Activity的边界，它将在触发时将正常流程更改为异常流程。

Visual Paradigm - DIY實例 

描述：此業務流程圖示例說明了業務部門與人力資源部門的流程，首先報告職位空缺並發布職位廣告，其中包括流量，任務，開始和結束事件以及網關。使用此BPMN圖表模板開始構建您自己的。自定義BPMN圖以反映您的組織。點擊使用此模板開始。

繪製圖

• 使用此模板 
• 創建空白 

其他例子

• 業務流程圖示例
• 所有圖示例