当前位置:首页 >  生活服务 >  了关于BPMN建模方法

了关于BPMN建模方法

发布时间:2021-01-12 11:40编辑:小狐阅读: 3次 手机阅读

导语:BPMN是业务流程建模和标注,很多企业都会通过BPMN对业务进行,提高整体的效率;但BPMN在国内的理解度还不够,本文以一个物业维修流程为例,了关于BPMN建模方法,我们一起来看一下。

BPMN(业务流程)是一种用于捕获、设计、执行、记录、测量、监控和控制自动化以及非自动化流程,以满足公司的目标和业务策略的方法。

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

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

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

了关于BPMN建模方法(图1)

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

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

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

澄清什么是,和什么不是这个流程的一部分。

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

在对流程着手优化前先对其进行一个大致的回顾。二、战略流程模型的要求

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

语法:尽可能正确,但是在必要时可以不那么严谨。三、战略流程模型的建模步骤

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

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

客户参会人员:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发起人填写一个维修单,发单部门(也就是行政部)将维修单提交到中心,中心的经办人填写工程单汇总表,把维修任务下发到维保部门,主任分配工作给维修工,维修工执行任务,并会同发单部门验收以确认维修完成。

当维修完成的时候,这个流程也就结束了。

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

了关于BPMN建模方法(图2)

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

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

1. 泳池和泳道

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

因此这边应该建模成流,另外,应当把业主分配到另一个池里。

了关于BPMN建模方法(图3)

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

2. 任务和子流程

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

子流程应该细化流程模型,在维修流程模型中,我们定义的这些任务,背后可能并不简单,他们可能对应着非常复杂的操作。

但是对于发单人填写登记表这类任务,从我们得到的信息来看,只管填就行了,所以我们就还是把它们当做任务。

基于这些考虑,我们可以得到下面的模型:

了关于BPMN建模方法(图4)

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

3. 网关

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

4. 事件

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

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

了关于BPMN建模方法(图5)

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

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

四、操作流程模型 1. 目的和好处

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

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

流程人员:需要通过流程引擎来实现什么功能?

流程参与人员:该怎么完成自己的工作?

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

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

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

藉由流程引擎实现的流程,更易于观测。2. 建模要求

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

3. 工序

了关于BPMN建模方法(图6)

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

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

设计者的工序可能如下:

战略流程模型。

分割泳道到单独的池。

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

为技术层面的建模做准备。

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

加上必要的注释。

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

4. 从战略层面到操作层面

继续我们的物业维修流程例子,为了简化对于每个流程参与者的模型复杂性,我们需要将物业公司下面的三个参与者泳道都分割到单独的池中。

同时,我们也要解决一些显而易见的逻辑上的错误,比如:

验收没有联合业主一起。

省略了仓管这一参与者。

省略了专员的每周汇总和进度督促。

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

了关于BPMN建模方法(图7)

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

5. 站在不同参与者的视角建模

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

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

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

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

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

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

了关于BPMN建模方法(图8)

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

了关于BPMN建模方法(图9)

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

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

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

是小修,中修,还是大修?

是否需要收费?

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

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

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

了关于BPMN建模方法(图10)

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

主管分配工作的细节。

是否应当记录返工次数?

区分不同级别的维修项目。

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

了关于BPMN建模方法(图11)

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

了关于BPMN建模方法(图12)

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

了关于BPMN建模方法(图13)

五、技术流程模型设计

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

了关于BPMN建模方法(图14)

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

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

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

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

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

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

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

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

下面给出第一版的技术流程实现:

业主流程:

了关于BPMN建模方法(图15)

接线员流程:

了关于BPMN建模方法(图16)

行政部流程:

了关于BPMN建模方法(图17)

中心流程:

了关于BPMN建模方法(图18)

维修主管流程:

了关于BPMN建模方法(图19)

维修工流程:

了关于BPMN建模方法(图20)

仓管流程:

了关于BPMN建模方法(图21)

回访流程:

了关于BPMN建模方法(图22)

专员催修:

了关于BPMN建模方法(图23)

专员统计:

了关于BPMN建模方法(图24)

六、结语

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

BPMN是一个很深的学问,根据业务的复杂程度,它的建模方法和难度都会大不相同,甚至会有和CMMN结合使用的情况。

至此,本文就告一段落了,希望我的文章能引起身为读者的你的思考。

悉尔科技 LLLimbo

本文相关词条概念解析:

流程

流程,指水流的路程。事物进行中的次序或顺序的布置和安排。英文为course,technologicalprocess。

建模

建模,是指使用计算机描述一个系统的行为。就是一个实际系统模型化的过程。对于同一个实际系统,人们可以根据不同的用途和目的建立不同的模型。建立系统模型的过程,又称模型化。建模是研究系统的重要手段和前提。凡是用模型描述系统的因果关系或相互关系的过程都属于建模。因描述的关系各异,所以实现这一过程的手段和方法也是多种多样的。可以通过对系统本身运动规律的分析,根据事物的机理来建模;也可以通过对系统的实验或统计数据的处理,并根据关于系统的已有的知识和经验来建模。还可以同时使用几种方法。

标签:
  • 网友评论

生活服务本月排行

生活服务精选