业务流程管理(BPM)产品设计

BPM也就是流程,在流程中,可以自己一个人独挑,也可以进行团队合作,均需按流程完成。那么,如何进行业务流程管理设计呢?一起来看一下吧。

一、浅谈什么是BPM?为什么要搭建BPM?

BPM说简单点就是流程,比如把大象装冰箱一共分几步,这就是流程;这个流程中,可以自己一人独挑,也可以进行团队协作,均需要按流程完成。

企业搭建流程的目的:规范员工行为和高效管理。就跟流水线一样,每个人负责1个环节或者多个环节,这样效率更高,员工的替换成本也低;(流水线作业)

企业的搭建流程中心的主要是为了逐步实现标准且固化的业务流程,让每一个员工像产线工人一样,去执行标准的行为和动作,以达到提升企业效率,降低运营成本的目的。

每次说到这里,总有人抬杠,企业很多制度和流程,并没有提升企业效率,比如明明不需要审批的,却要审批或者明明可以一步做完的,非要分几步等等。这个可以从两方面考虑:

  1. 企业的制度有问题,这一点可以参考麦当劳兄弟设计出餐流程,这时候是需要优化流程;
  2. 没有理解该制度和流程的精髓,因为有时千里之堤毁于蚁穴;

如果还要继续battle,那我只能告诉你,要么优化,要么执行,要么走。

二、设计概要

在企业中,万物皆可流程化;大到项目运转,小到橡皮借用,皆可进行流程化;流程很重要,我常比喻为“指挥棒”、“指路牌”、“打钉枪”。

  1. 指挥棒:站在管理者角度,依托标准化流程可以指挥企业各项工作的顺利推进;
  2. 指路牌:在工作/项目角度,在每一个阶段和过程中,告诉执行者应该做什么,应该怎么做;
  3. 打钉枪:站在员工角度,需要把工作当做钉子,钉在该有的位置;

在企业信息化过程中,会碰到各种流程,常见的几种场景:

  1. 审批流程:比如请假流程、报销流程;
  2. 工作流程:比如项目交付、合同签订,都是有明确的步骤和业务动作(跟大象装冰箱分3步一样);
  3. 自动流程:无需人工,满足条件即执行;比如每创建一个客户后,自动给客户发送产品宣传邮件;

从以上的场景,我们可以清楚的知道,流程是存在多种场景和多种业务对象里的;尤其是一些业务多样化企业或者大中型企业,相同的部门和业务也有不同的流程,不同的人群不同的业务有不同的流程,这种多样性和复杂性从本质上决定了流程中心的发展需要高度抽象化和配置化(需要将流程和业务解耦,各自干各自的,相互不影响/较小的影响)。

如果每项流程都单独做,会有重复工作且数据不通,无法分析和统计企业工作。

所以,BPM设计要遵循以下原则:

1)独立性

流程和业务看做是两个独立的人,只是在相互合作时,严格区分哪些是你的,哪些是我的;毕竟你能给我的,别人也基本能给我;而我的就是我的,我会越来越丰富,能力越来越强。(你指业务,我指BPM)

2)开放&集成

BPM要多个系统集成,也就是要跟多人同时合作,要做好开放对接能力和做好数据集合&区隔;要建立开放平台,明确好对接规则,这样满足规则并经过授权的都可以使用。

3)数据&效能

企业运营会产生大量数据,BPM要有数据管理的能力,也要保证一定的数据处理效率,所以做好全面数据存储和区分就非常重要,数据库架构要在初期构建时,就要搭建好,这个要同技术详细沟通。

4)安全性

各个系统的数据都要对接BPM,不光内部要做好权限控制,也要保障数据安全,防止黑客攻击或未经授权的数据检索;也就是说,跟多人同时谈恋爱,什么该做什么不该做,要区分清楚,还要防止偷窥隐私,做时间管理大师!

5)流畅性

每个系统可能有独立的账户体系,要支持单点登录(SSO),在业务系统可直接访问;做好账户管理,让用户在多平台上轻松登录和访问;对于流程执行的事项,要有跟进和反馈,并进行及时通知,给流程加加速。

图1:业务流程管理流程

名词解释:在考勤系统中,提交请假单为例:

  1. 实例数据:业务对象具体的数据,比如请假单,员工张三请假3天、开始结束时间等,这就是实例数据;
  2. 业务系统:执行具体业务的系统,考勤系统、CRM系统、费用管理系统等;
  3. 业务对象:也就是我们常说的表单(实际也有略微区别,对流程中心可忽略,以下皆称为表单,方便理解),比如请假单、订单都属于业务对象;
  4. 事件:满足一定条件后,执行的工作内容,如发送短信、发送通知等;

三、BPM设计

流程中心设计,首先要明白流程的本质是按照流程进行事务办理,那么可以将流程中心抽象为:人、节点、事(也就是说什么人在什么节点做什么事),映射到产品设计上就是:执行人、流程节点、操作/事项配置。

流程中心作为多系统管理的中台能力,在实际的应用中,要具备管理能力和业务实时交互能力。

对于一个完整的业务流程来说,至少有4个环节:对什么业务进行处理、这个业务有什么样的动作、什么人在哪个节点上做什么事、最后对流程进行监督和管理。

综上,BPM(业务流程管理)至少要包括5大部分:表单管理、流程应用、流程引擎、事件管理、流程管理。

图2:业务流程管理产品结构

1. 表单管理:先把工作明确下来

表单管理即流程中心的需要明确的工作内容,比如合同、订单、报销单、加班单、出差申请等等,需要应用在流程中进行处理的工作。

  1. 表单分类:方便业务处理,比如可以分为财务、销售、考勤,为了适应复杂的业务逻辑,表单分类可放宽到多级分类,建议用4~5级;
  2. 自定义表单设计:不涉及复杂业务场景的,需要进行流程处理的工作,可以利用表单设计器拖拽设计表单;(可根据业务实际场景,增加字段类型:输入型、选择型、功能型,也可以把常用场景进行组装为组件)
  3. 三方表单接入:一般业务都会有自己的业务表单且有复杂的业务交互逻辑,通过表单设计器是无法完成设计的,流程中心也需要对接三方系统的表单;
  4. 字段管理:表单的字段,需要进行统一的管理;作为中台,需要开发接口,支持三方字段更新,并且中台要能够有一套独立的字段ID映射管理体系,避免多系统、多业务字段冲突。

2. 流程应用:把工作进行拆分

表单对接完成后,工作类型也就确认了,接下就是把工作中涉及的内容进行拆分;发起流程后,不同的节点由不同的人进行办理,那么这些人办理什么内容呢?

所以流程如果想要应用起来,需要提前将表单对应的工作做好,包括:触发入口整理(哪里能够触发流程)、流程操作注册(流程办理人需要完成的操作)、待办数据和已办数据。

流程应用,需要重点抽离出表单对应的业务动作,比如审批、办理、确认、分派、自动任务;在产品设计时,对应的重点是抽离不同表单的操作并组装成流程动作。不同的动作,包含不同的操作;不同的按钮对应不同的行为。

  • 审批:由执行人进行审批操作。(通过、驳回)
  • 办理:由执行人进行业务办理。(办理、结束办理)
  • 确认:执行人仅需对业务数据进行等待并确认。(确认)
  • 分派:执行人可以自定义下一个节点的执行人及对应动作。(分派)
  • 自动任务:对应的执行人仅接收数据无需进行任何操作,流程自动向下流转。可用于业务数据同步和自动事件执行,如合同签订后,自动生成发票申请并通知财务。

业务动作还会配套一些通用的操作,可在节点上进行权限控制,如评价、下载、打印、挂起/继续、加办、转交。

业务动作的梳理是一个大工程,除了要跟业务系统在动作上达成共识以外,还需要对不同的业务动作及其操作进行抽离,最后还需要适配业务系统的权限控制。

按钮操作的点击行为常见的类型:打开页面、打开弹窗、触发、指定动作;按钮操作的执行内容常见的有:流程关联(推进/退回/插入/删除)、办理。

以上内容就将工作进行了拆分,也就是说,把当前这个表单需要流程推进的工作进行拆分,可以配置给不同的执行人进行办理。

3. 流程引擎:设计工作流水线

流程引擎主要就是完成人-节点-事配置:

  • 人:什么人可以触发流程?发起的数据能够满足触发条件?什么人处理事务?
  • 节点:工作流程怎么配置?节点有哪些规则?处理的约束条件有哪些?
  • 事:要处理的工作内容?

1)流程分类

随着企业的发展,会有成千上万的业务流程;如果没有合理的流程分类,员工在使用时、管理员在管理时也会不知所措,所以流程一定要进行有效的分类。建议可以按照部门进行管理,也可以面向业务进行管理。分类一定要认真思考,要充分考虑公司自身的业务,比如业务流程偏通用型的,可按业务类型进行分类;若部门流程千差万别且存在多种业务流程,则可以按照部门+业务进行区分。

在产品设计时,要支持多级分类创建和管理,同时要支持批量迁移和分类合并。

2)基本信息

基本信息包括:流程名称、流程分类、面向表单、流程说明、适用范围。

  • 流程名称:名称是为了更好的对流程进行区分,产品设计时,如果相同人群面向同一业务有多种流程时,名称支持流程标签的插入;
  • 流程分类:支持从分类中直接创建;
  • 流程触发器:是指流程可用于哪些用户,满足什么条件下进行触发;用户一般是指实例数据的提交人,而条件触发多用于高级一些的配置,可面向表单字段进行配置(表单字段应取所有字段);

流程触发包含:用户&条件。

肯定有同学会问触发条件和流程绘制时的条件分支有什么区别?

从应用场景上来讲,条件分支是可以满足的,但是触发条件和用户都属于触发器配置,实际应用中,条件触发用于不需要触发流程的数据,不用生成流程数据。

①用户:支持多态用户(部门、指定用户、用户组、角色、职能、角色组)

图3:多态用户选择

②触发条件:面向表单配置条件,选取字段进行条件匹配;以下给个参考:

图4:触发条件配置

如果企业/组织体系较大时,流程管理权限是可以下放的,需要对用户进行权限控制的。

3)推进规则配置

推进规则用于控制整个流程的规则,如果场景比较单一,推进规则可以写死,当要面对多业务场景或者SaaS系统,对于流程的规则要支持多场景配置。

举几个例子吧!

  1. 是否支持推进到任意阶段还是必须按阶段进行推进,可以向前还是向后;
  2. 是否支持流程结束后,重新激活;
  3. 是否支持去重:比如一个人在流程中需要处理多次,是否可以自动跳过;

还有很多其他规则就不一一罗列了,以上规则还有很多细分规则,比如有必填任务时,是否支持推进等等。

规则要结合自身的业务发展,逐步完善,不必刻意追求一步到位。

产品设计时,要把最常用的全部进行默认;比如常见的审批流程,就是必须按阶段向后逐个推进。

4)流程图绘制

流程图绘制,目前市面上较为流行两种,一种是flowable,一种是像钉钉和飞书那种线性结构;各有优劣吧!总体来讲,流程较为复杂的可以采用flowable绘制,流程较为清晰明了且为了降低操作难度角度考虑,可以采用线性结构;流程图绘制组件主要包括:开始、业务动作、网关、结束。

一个流程中,至少要有一个开始节点和一个结束节点。
开始:只有一个,比较明确;

业务动作:主要配置人、事、节点规则,具体的业务动作可以按照流程应用进行拆分配置;常见的有审批、办理、自动任务、计算校验;

网关:网关可以理解为分流器(即分支),主要分为条件分支、并行分支、并行+条件分支;

图5:网关示意图

  • 条件分支:只能进入其中1个分支,需要添加条件规则,产品设计时条件规则必须配置优先级,不然会出现条件规则交叉情况,导致系统错误;
  • 并行分支:同时进入多个分支,无需添加条件规则;

并行+条件分支:只要满足条件规则的分支,都可以进入;

并行分支在产品设计时,要注意分支合并和单独结束的情况。

5)节点执行人

节点执行人,表示当前节点的业务动作需要执行的人员范围;这个范围主要包括3种类型:用户、流程相关用户、数据相关用户;

  • 用户:支持多态用户(部门、指定用户、用户组、角色、职能、角色组);
  • 流程用户:指定节点的办理人、办理的上级、同步指定节点规则;
  • 数据用户:表单内字段对应人/角色/部门、数据相关人(创建人、归属人、修改人、提交人)、数据相关规则(创建人/归属人/修改人/提交人–连续多级/上级/部门负责人);

6)执行人规则

当我们选取了节点执行人后,必然会出现两种情况:存在多人、压根没有人;存在多人时,系统无法判断如何继续向下流程;压根没有人时,流程会出现中断,信息会出现丢失;所以,这两种情况要进行处理,常见的处理方式为:

  • 会签:多人时,所有人都需要进行执行办理;
  • 或签:多人时,仅需1人进行执行办理;
  • 为空:压根没有人时,可以进行指定人、指定管理员、或者支持一些规则,比如连续多级、追踪角色等;

特别注意:以下情况可在推进控制管理时,需细化配置规则。

  • 离职会影响正常审批,也会造成为空;
  • 去重会影响会签/或签;
  • 为空追踪会持续为空,应设置管理员托底;

7)节点操作配置

在业务动作约束下,配置不同操作名称及工作内容;

以审批为例:

①设置操作内容

图6:业务动作(审批)操作设置

②设置工作内容

图7:业务动作(审批)工作设置

8)节点超时控制

节点超时控制,主要用于对于流程节点有时间控制的需求,比如设备维修;主要包括2个方面:截止时间控制、节点时限规则;

截止时间控制:主要约束节点流程没有任何处理,出现停滞;但该节点又比较重要时,可以对当前流程进行强制约束;比如自动转交、自动通过、自动拒绝、自动办理、事件触发;也可不进行超时控制,那么待办任务将自动添加超期标签;

节点时限规则:对当前节点可添加时限规则,用于控制节点停留时间,加快流程流转效率;节点时限规则,可以同时配置多个;比如不同时间内,发不同的消息提醒;

时限计时方式一般按照2种方式:固定时间、接收后计时;

满足时限规则后,可以进行流程约束:自动转交、自动通过、自动拒绝、自动办理、事件触发;

9)节点规则配置

节点规则配置,是因为在实际业务流程中,会出现临时性情况,执行人拿不定主意或者自己完不成时,需要进行加办;比如某项工作无法进行评估,可邀请专家一起;

固化的流程也会因实例数据的特殊性,流转到非工作范围内时,可进行转交;比如某项维修单,数据比较特殊,需要指定人进行处理;

一般节点规则配置主要包括:加办、转交、抄送;

图8:节点规则配置

  1. 加办:分为前置、后置,也会有单人/多人之分;所以,在执行加办时,要能够支持前后的选择,同时也可配置或签/会签;
  2. 转交:节点当前执行人,因临时情况/不在工作范畴内时,可将任务进行转交,转交是将执行人进行替换,同时继承当前节点执行人的所有数据及规则;
  3. 抄送:主要用于节点特别需要对部分用户进行数据查阅控制;

10)流程管理

流程管理主要包括:流程版本、实例编号。

  • 流程版本:流程在应用过程中,会不断的调整和优化,每次调整都应创建新版本;以避免在运行的流程数据出现问题,也就是说在运行中的流程仍然用旧版本,新发起的/驳回重新提交的,才会使用新的版本。
  • 实例编号:对实例数据要进行编码管理,根据业务表单情况,进行编码规则管理;实例数据出现多次触发单一流程或者触发不同流程时,可根据实例编号进行流程数据整合。

4. 事件管理:干完活后是发奖金,还是抽鞭子

事件管理,主要用于在进行某种操作/变化时,进行事件触发;所以事件管理主要包括事件捕获和事件触发;

  • 事件捕获:根据流程中配置的事件触发机制进行定时捕获、消息捕获、操作捕获;为了确保系统的可靠、准确,在产品设计时要有补偿机制;
  • 事件触发:当流程执行到事件,会触发一个事件,在流程中,常见的事件类型有通知消息、短信、邮件、业务流程触发、新建/更新表单数据;

5. 流程管理:时刻关注工作的进度

作为多业务系统流程管理,需要对流程进行实时监督,以便完成企业特定目标;流程监控可以帮助企业分析流程的性能,找出关键问题,改善业务流程的速度、质量及效率。

流程管理主要包括:流程监控、异常流程管理、流程强制介入、流程时效分析;

  • 流程监控:对流程数据进行实时监控,可查看数据详情和流程实时进度,监控流程的持续时间、完成情况等;
  • 流程异常:对流程数据中,如果出现异常情况,进行监控,比如节点为空、审批人离职、流程超时等情况,以方便对应管理员对相关流程进行优化调整;
  • 流程强制介入:对流程数据进行强制性处理,常见的有:转交、强行中止;
  • 流程时效分析:耗时分析、使用分析、时效分析、超时统计等;

最后:抓不住老鼠的,都不是好猫。

面向实际业务中,只要在整体框架无误的基础上,降低一定的灵活性也是可以的,快速实现、快速应用、快速迭代方为上策。

无论多么流畅、多么强大的流程,不能对业务产生增益,都是失败的!

本文由@张三丰 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

网站声明: 1.本站大部分资源搜集于网络,仅代表作者观点,如有侵权请提交修改。 2.网站内容仅网站站长做个人学习摘记,任何人不得用于其他商业用途,网站发表的内容全权归原作者所有。 3.有任何疑问,可以点击右侧边栏的联系QQ进行咨询 4.本网站部分内容来自于其他网站平台的,版权归原网站所有,本网站只作信息记录,自己学习使用,特此申明,本站用户也不得使用此信息内容做其他商业用途。
白丁学者 » 业务流程管理(BPM)产品设计