php审批流并发技巧_后台系统设计工作流设计剖析

一样平常在轻微繁芜一些的后台系统中，事情流的设计是不可避免的一个主要部分。
设计好一个后台事情流，不仅可以使得后期利用系统的时候更加高效，同时也是十分磨练产品经理的。
刚比如来自己在做这方面的事情，以是总结了一些方法履历与大家共勉。

一、理解什么是事情流及事情流的类型

在企业级的一些系统中，事情流是非常常见的一个赞助功能，由于许多操作是无法通过操作者一个人来完成的。
在后台系统中，用到事情流的我认为大致可以分为以下两个方面：

①涉及到流程审批的系统功能

事情流涉及到流程审批的系统很常见，比如一样平常OA中的请假申请，加班申请，出差申请；人事系统中的入职流程审批，离职审批。
公司内部如果有业务系统中某些比较主要或者比较谨慎的操作，也须要层层审批。

对付流程审批类的事情流，其特点为会将审批的角色划分为生产者与处理者。
生产者即生产数据的角色，其在事情流的事情为新数据的添加；处理者即对已有数据的进行某些操作。

从某种意义上讲，事情流所进行的某些功能操作因此处理者的需求进行设计的。
只是由于某些生产类型的事情较为低级，或者某些生产事情较为繁琐，处理者的职能地位已经不许可他去做这些事情，以是这些事情就被“下放”到了生产者当中，而处理者只须要判断一下生产者的事情是否进行得当，并且提出一定的见地，让生产者不断地修正以期达到处理者终极想要得到的目的。

例如在进行请假审批的时候，领导须要看到的是请假者请假的事由，天数，请假类型等等，而不是请假者为了让领导看明白自己将请假的内容填写的详尽。
以是我们在设计流程审批类的事情流时，需求方更多的要从处理者去考虑，要去把握他们须要什么，再从中去设计定义内容。

②须要多人协作完成的事情

对付此种事情流来说，其目的紧张是为了让某个角色更加专注的去进行某项事情。
类似于流水线事情，在系统中所表示的便是到了哪一个步骤就将该事情流程流转到某个角色，完成后再流转到下一个角色，将所有的角色的事情流程串接起来，便是某项事情完全的事情流程。

比如电商后台中WMS的库存盘点。
此功能的事情一定要涉及到核对采购单，核对发卖单，入库盘点，差异登记，库存更新等这一些列的操作，而这些操作则可以大略分为盘点前，盘点中，盘点后。

以是其流程就可以按照功能设计成这样：首先采购职员、发卖职员报备采购单、发卖单，接着库管职员进行库存盘点，末了数据记录职员进行差异登记，库存更新，三个部分相互独立却又依次关联。
关于此种类型的事情流，梳理前后逻辑关系流程，进行有效的功能拆分。
并且可以通过某些操作将其串联起来是设计中的重点。

二、事情流的设计要点

那么，在理解什么是事情流后，要设计好一个事情流，该当要考虑以下几个设计要点。

首先，我们按照一个正常事情流的功能，可以将事情流拆分成以下几块内容。

对付流程审批类的事情流来说，事情流内容的生产端一样平常来说角色等级都比较低，仅仅作为数据的记录者而没有任何的处理权限。
以是在设计的时候，任何可以在生产端直接进行数据处理的操作都要慎重考虑。
比如，是否许可数据基本的录入者直接进行编削的权限？

某些对付数据状态的变更是否可由其进行变更。
而进行到了数据的处理阶段，终极要对该项功能所填写的数据进行产出，而在处理阶段的操作，可以分为两种情形：

这两种流程角色的不同，定义着其在全体流程中的操作不同，一个只做通过驳回挂起等流转性操作，一个却可以进行信息的补充，编削，以及其他内容的添加。
在设计事情的时候，要理清处理阶段的角色事情模式，才能将事情流设计好。

对付多人协作的事情流来说，其每一个角色都是数据的天生者，每一个角色也都是数据的处理者。
这个时候，类似于流程审批类的处理权限掌握就没有必要设计了。
由于每一个流程操作的内容划分的都很明确，流程与流程之间的操作并没有重叠之处，上一个流程的操作只是作为一个流程的前置支撑而已。
以是在这个时候，要处理好的是角色之间的功能拆分，确保每一个角色每一个流程所进行的操作都是在流程下的充分必要条件。

关于数据的消费，指的是数据产生后是为了做什么。
对付不同的角色来说数据的产生有着不同的功能，在设计事情流的时候，也要适当的把这些考虑进去。
由于我们设计的时候每每只关注数据的天生，而不去关注天生之后他要去做什么。

比如我最近在做的一套商管系统，签订条约完成后是为了天生店铺，进行店铺的操作，以是数据审批完成后就该当抄送一份给店铺管理的角色。

比如某些采购单审批通过了 ，可能消费数据的并不是采购货色的职员，还有财务职员须要进行入账处理，以是数据该当也给财务一份。
以是我们在设计事情流的时候，不仅仅要考虑到数据在全体事情流中的直接消费者，其间接消费者也应该进行考虑设计。

第二、不同情形的事情流状态

一样平常来说，一个审批类事情流的状态只从流程上来说的话大致可以分为这几个阶段：未审批–审批中–审批结束。
不同的阶段又可以拆分身分歧的情形。

比如在未审批的情形下，可能会有已经填写但是未提交到事情流的情形，也可能会有已经提交到事情流但是创造提交内容出错无法撤回的情形。
以是在审批的情形下，视情形可以添加保存的操作（对应的事情流状态可为未提交）；紧急撤回的操作（对应的事情流状态可为已撤回）。

在审批中，除了正常的一个节点一个节点的审核外，可能会碰着的情形还会有该条事情流流转到这里时已经废弃了，此时可以加上废弃的操作（对应的事情流状态可为已废弃）；还有可能流转到这里时创造全体流程有问题或者由于其他缘故原由对付全体事情流有异议，但是可能该节点还有其他角色可以进行操作，以是须要将事情流暂时冻结，待确定后再重新激活，以是此时事情流该当加冻结/挂起的操作（对应的事情流可为已冻结），以及对应的重新激活的操作（对应的事情流状态展示即回到原有事情流的状态）。

同时，在审批中可能由于会有多个事情流的操作，但是这条操作比较焦急，以是在数据的生产者端可以加上加急处理的操作，此时在处理者中看到的此条记录应该为置顶状态。
但是由于加急处理的权重比较高，以是并不是每一个角色都授予这个操作权限。
末了，该当给审批中设置一个审批时效，超时后是应该进行超时作废还是超时退回也该当有明确的目标。

末了，是审批结束，其也分为两种情形：

一种是审批通过，一种是审批不通过。
对付审批通过，即为该条记录天生完成，可进行消费者的抄送等等操作，审批不通过，一样平常可以为驳回状态。
对付驳回状态，设计者须要考虑的是完备驳回还是驳回到上一个节点。

如果是完备驳回，则须要操作者重新填写提交。
如果是驳回到上一个节点，则上个节点的处理者该当有数据的编辑权限，由其进行二次编辑后重新提交其优点时流程较为优化，韶光可缩短，缺陷为并不是所有的处理者都有编辑权限，逻辑方面须要设计者思考。

对付协同事情类的事情流，事情流的状态相对来说便是比较大略的了，其每一个流程节点都是独立的，只有上一个节点的事情完备完成后，才可以流转到下个节点，而且由于其没有存在审批流的功能，以是在该节点填写完成，提交至下一节点后当前节点的事情的事情就完成了。
到下一个节点时与上一个节点逻辑相同直至结束。

三、事情流程的订定及角色的划分

这一点只针对审批类的事情流进行阐述。

传统的事情流程来说大致可以分为这样几种情形：自由/半自由流程、固定流程、分支流程、并发流程与实行、并发流程或实行。

自由流程指的是从生产者到处理者每一个流程节点都可以由上个节点的操作者指定角色，半自由流程指的是指定角色的时候限定一定的范围。
固定流程指的是流程是所有的流程即角色都是固定好的，不能修正。

这种情形的优点和缺陷都极度的明显：优点即操作大略，逻辑大略，开拓难度小。
缺陷为实用性较小，较为去世板，不足灵巧。

分支流程指的是当流程知足某一个跳转条件时即进行流程的跳转实行子流程，当流程实行完毕后再跳回到主流程进行接下来的流程操作。

比如某次采购单的采购，当采购金额小于100万时须要采购经理即可进行审批，昔时夜于100万时须要副总级别的人物进行审批后才可以进行。

并发流程与实行指的是多个流程共同实行，所有流角色程都实行完毕后才流转到下一个节点，比如某次项目的开始须要招商部，企划部，工程部共同完成。
只有当这些角色都审批完成了才能开始。
并发流程或实行指的是多个流程共同开始，只要有一个角色进行审批了，则流转到下一个节点。
在此不做赘述。
在一样平常涉及到事情流的后台中，这几种情形大致就可以知足。

以上可以称之为标准事情流，即后台给予固定的模板，干系配置职员进行配置即可。
但是，在有些繁芜的后台系统中，可能因此上几种情形共同涌现的，也可能是涌现了其他情形，这个时候，就须要整体流程定制化的操作。

那么，要设计一个非标准事情流，首先是分清上文提到的角色、内容、流程之间的关系——即角色与内容是挂在流程节点上的功能点。
以是我们只须要将流程节点掌握好，再将不同的角色，以及对应的操作内容挂靠上去即可，这样一来是可以方便理清关系，其余也可以使系统更有层次。

以是接下来我们只须要将流程节点掌握好即可。

掌握好非标准流程节点，可以由以下几个方面动手。

第一、如果流程配置者有配置SQL的能力，那么将数据库流程配置权限开放，让配置者自行配置，这样的开拓事情压力会小一些，但与此同时，风险也会很大。

第二、画流程图的办法。
一个流程的实行可以通过流程图来表现，对付产品经理来说是再熟习不过了。
通过流程图的基本逻辑，可以将流程中碰着的各种情形可视化的展示出来，条理清晰而且操作大略。
缺陷即开拓难度过大，一样平常小团队难以胜任。

第三、通过逐一配置功能来进行配置，这种办法虽然表面上看起来十分的繁琐，但是相对付前两种来说开拓难度小，且对付配置者的能力哀求不高。
详细来说，要单独配置每一项功能的流程，先确定流程的主流程有几个节点，如果碰到判断的节点选择是，碰到并发流程或实行的节点选择最长的一个流程。
确定之后，将所有节点的内容操作与角色配置出来，然后再配置该节点是否进行判断，是否进行或操作，是否进行与操作。
如果有判断操作时，则分出一个子流程，再将子流程按照上述办法进行配置，终极归于主流程的某一个节点。
如果有与操作时，要确定配置与操作的分支节点时是要配置在单个节点还是多个节点。
单个节点的话则需知足这两个节点才往下进行，多个节点时则将这几个节点作为一个小流程单独按照上述办法进行配置再合并至主流程，看是否知足与行为。
如果有或操作判断时，同样要确定在哪个节点的或操作至哪个节点可以进行其余的节点流转。

以上这些情形对付开拓团队来说也是一个巨大的磨练，由于不同的事情流程代表着不同权限的操作，不同状态的流转，而可定制化的流程则代表着个中的变革无穷，对付做事器的压力，数据库的冗余情形都不容乐不雅观。
接下来的部分，我会大略的分享一下如何才能高效的设计非标准事情流。

三、如何设计高效的非标准事情流

设计一个后台压力小，操作大略的高效非标准事情流，我总结了两个办法：第一、将非标准事情流拆分成多个标准事情流。
第二、开辟独立与配置权限之外的事情流角色模块。

第一、将非标准事情流拆分成多个标准事情流

一个非标准事情流固然麻烦，可是在大多数的情形下，其可以拆分为几个标准事情流。
比如，某个非标准事情流可以线性拆分为多个分支流程，并发流程与实行、并发流程或实行。
将其每一个组合到一起，即可形成完全的事情流，那么我们就可以在系统中供应组合模板，让配置者可以进行选择，组合到一起形成一个非标准事情流。

如果是非线性的，比如可能为分支套分支，并发套并发的情形，我们可以将每一种情形都拆分成一个事情流，然后将生产端入口保持统一，每一步的不同操作可以进入不同的事情流，终极流转的出口保持同等即可。
有点类似于开拓中设计模式的工厂模式。

第二、开辟独立与配置权限之外的事情流角色模块

一样平常来说，我们在配置事情流角色的时候，都是利用类似权限掌握的角色，比如到这个节点角色为库管，另一个节点角色为商管。
实在换个角度想想，再说设计事情流的时候，完备可以设计一个独立于权限之外只配置事情流的角色。

比如“分支节点角色1号”“流程角色1号”“并发或角色2号”，然后再通过穷举法，将所须要用到的利用流程都列出来，把角色放置于节点上。
这样，一个活的须要配置的流程就变成了一个个的去世流程。
再将这些角色授予权限角色。
再定义一些规则：比如若没有配置此节点的角色则此节点默认通过，将某个事情流角色配置两个权限角色则为或操作/与操作。
这样也就办理了上述的问题。

事情流可以说是后台 系统中比较繁芜的一部分。
即便某些系统中一开始没有事情流，随着系统功能的增加，也不可避免会用到事情流，以是提前理解下事情流的设计方法，对付产品来说很有帮助，在开始设计的阶段也可以考虑将内容设计进去以免后期掩护本钱过大。

专栏作家

执迷，微信"大众年夜众号：执迷有悟，大家都是产品经理专栏作家。
电商O2O领域，关注数码硬件，人工智能，新闻资讯领域。

本文原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Pexels，基于 CC0 协议