一般在稍微复杂一些的后台系统中，工作流的设计是不可避免的一个重要部分。
設計好一個後臺工作流，不仅可以使得后期使用系统的时候更加高效，同时也是十分考验产品经理的。
一、了解什么是工作流及工作流的类型
在企业级的一些系统中，工作流是非常常见的一个辅助功能，因为许多操作是无法通过操作者一个人来完成的。
在后台系统中，用到工作流的我认为大致可以分为以下两个方面：
①涉及到流程审批的系统功能
工作流涉及到流程审批的系统很常见，比如一般OA中的请假申请，加班申请，出差申请；人事系统中的入职流程审批，离职审批。
公司内部如果有业务系统中某些比较重要或者比较谨慎的操作，也需要层层审批。
对于流程审批类的工作流，其特点为会将审批的角色划分为生产者与处理者。生产者即生产数据的角色，其在工作流的工作为新数据的添加；处理者即对已有数据的进行某些操作。
从某种意义上讲，工作流所进行的某些功能操作是以处理者的需求进行设计的。只是因为某些生产类型的工作较为低级，或者某些生产工作较为繁琐，处理者的职能地位已经不允许他去做这些工作，所以这些工作就被“下放”到了生产者当中，而处理者只需要判断一下生产者的工作是否进行得当，并且提出一定的意见，让生产者不断地修改以期达到处理者最终想要得到的目的。
例如在进行请假审批的时候，领导需要看到的是请假者请假的事由，天数，请假类型等等，而不是请假者为了让领导看明白自己将请假的内容填写的详尽。所以我们在设计流程审批类的工作流时，需求方更多的要从处理者去考虑，要去把握他们需要什么，再从中去设计定义内容。
②需要多人协作完成的工作
对于此种工作流来说，其目的主要是为了让某个角色更加专注的去进行某项工作。类似于流水线工作，在系统中所体现的就是到了哪一个步骤就将该工作流程流转到某个角色，完成后再流转到下一个角色，将所有的角色的工作流程串接起来，就是某项工作完整的工作流程。
比如电商后台中WMS的库存盘点。此功能的工作必然要涉及到核对采购单，核对销售单，入库盘点，差异登记，库存更新等这一些列的操作，而这些操作则可以简单分为盘点前，盘点中，盘点后。
所以其流程就可以按照功能设计成这样：首先采购人员、销售人员报备采购单、销售单，接着库管人员进行库存盘点，最后数据记录人员进行差异登记，库存更新，三个部分相互独立却又依次关联。
关于此种类型的工作流，梳理前后逻辑关系流程，进行有效的功能拆分。并且可以通过某些操作将其串联起来是设计中的重点。
二、工作流的设计要点
那么，在了解什么是工作流后，要设计好一个工作流，应该要考虑以下几个设计要点。
首先，我们按照一个正常工作流的功能，可以将工作流拆分成以下几块内容。
1. 工作流内容的生产，处理，消费
对于流程审批类的工作流来说，工作流内容的生产端一般来说角色等级都比较低，仅仅作为数据的记录者而没有任何的处理权限。所以在设计的时候，任何可以在生产端直接进行数据处理的操作都要慎重考虑。
比如，是否允许数据基本的录入者直接进行删改的权限？
某些对于数据状态的变更是否可由其进行变更。而进行到了数据的处理阶段，最终要对该项功能所填写的数据进行产出，而在处理阶段的操作，可以分为两种情况：
只做流转操作，其流程节点可以理解为一个高级筛选功能，目的只是为了决定是否让此条数据流转到下一节点。
流转的同时需要进行数据的修改或者补充。
这两种流程角色的不同，定义着其在整个流程中的操作不同，一个只做通过驳回挂起等流转性操作，一个却可以进行信息的补充，删改，以及其他内容的添加。
在设计工作的时候，要理清处理阶段的角色工作模式，才能将工作流设计好。
对于多人协作的工作流来说，其每一个角色都是数据的生成者，每一个角色也都是数据的处理者。这个时候，类似于流程审批类的处理权限控制就没有必要设计了。
因为每一个流程操作的内容划分的都很明确，流程与流程之间的操作并没有重叠之处，上一个流程的操作只是作为一个流程的前置支撑而已。所以在这个时候，要处理好的是角色之间的功能拆分，确保每一个角色每一个流程所进行的操作都是在流程下的充分必要条件。
关于数据的消费，指的是数据产生后是为了做什么。对于不同的角色来说数据的产生有着不同的功能，在设计工作流的时候，也要适当的把这些考虑进去。因为我们设计的时候往往只关注数据的生成，而不去关注生成之后他要去做什么。
比如我最近在做的一套商管系统，签订合同完成后是为了生成店铺，进行店铺的操作，所以数据审批完成后就应该抄送一份给店铺管理的角色。
比如某些采购单审批通过了 ，可能消费数据的并不是采购货物的人员，还有财务人员需要进行入账处理，所以数据应该也给财务一份。所以我们在设计工作流的时候，不仅仅要考虑到数据在整个工作流中的直接消费者，其间接消费者也应当进行考虑设计。
2. 不同情况的工作流状态
一般来说，一个审批类工作流的状态只从流程上来说的话大致可以分为这几个阶段：未审批–审批中–审批结束。不同的阶段又可以拆分成不同的情况。
比如在未审批的情况下，可能会有已经填写但是未提交到工作流的情况，也可能会有已经提交到工作流但是发现提交内容出错无法撤回的情况。
所以在审批的情况下，视情况可以添加保存的操作（对应的工作流状态可为未提交）；紧急撤回的操作（对应的工作流状态可为已撤回）。
在审批中，除了正常的一个节点一个节点的审核外，可能会遇到的情况还会有该条工作流流转到这里时已经废弃了，此时可以加上废弃的操作（对应的工作流状态可为已废弃）；还有可能流转到这里时发现整个流程有问题或者由于其他原因对于整个工作流有异议，但是可能该节点还有其他角色可以进行操作，所以需要将工作流暂时冻结，待确定后再重新激活，所以此时工作流应该加冻结/挂起的操作（对应的工作流可为已冻结），以及对应的重新激活的操作（对应的工作流状态展示即回到原有工作流的状态）。
同时，在审批中可能因为会有多个工作流的操作，但是这条操作比较着急，所以在数据的生产者端可以加上加急处理的操作，此时在处理者中看到的此条记录应当为置顶状态。
但是由于加急处理的权重比较高，所以并不是每一个角色都赋予这个操作权限。
最后，应该给审批中设置一个审批时效，超时后是应当进行超时作废还是超时退回也应该有明确的目标。
最后，是审批结束，其也分为两种情况：
一种是审批通过，一种是审批不通过。
对于审批通过，即为该条记录生成完成，可进行消费者的抄送等等操作，审批不通过，一般可以为驳回状态。对于驳回状态，设计者需要考虑的是完全驳回还是驳回到上一个节点。
如果是完全驳回，则需要操作者重新填写提交。如果是驳回到上一个节点，则上个节点的处理者应该有数据的编辑权限，由其进行二次编辑后重新提交其优点时流程较为优化，时间可缩短，缺点为并不是所有的处理者都有编辑权限，逻辑方面需要设计者思考。
对于协同工作类的工作流，工作流的状态相对来说就是比较简单的了，其每一个流程节点都是独立的，只有上一个节点的工作完全完成后，才可以流转到下个节点，而且由于其没有存在审批流的功能，所以在该节点填写完成，提交至下一节点后当前节点的工作的工作就完成了。到下一个节点时与上一个节点逻辑相同直至结束。
三、工作流程的制订及角色的划分
这一点只针对审批类的工作流进行阐述。
传统的工作流程来说大致可以分为这样几种情况：自由/半自由流程、固定流程、分支流程、并发流程与执行、并发流程或执行。
自由流程指的是从生产者到处理者每一个流程节点都可以由上个节点的操作者指定角色，半自由流程指的是指定角色的时候限定一定的范围。固定流程指的是流程是所有的流程即角色都是固定好的，不能修改。
这种情况的优点和缺点都极度的明显：优点即操作简单，逻辑简单，开发难度小。缺点为实用性较小，较为死板，不够灵活。
分支流程指的是当流程满足某一个跳转条件时即进行流程的跳转执行子流程，当流程执行完毕后再跳回到主流程进行接下来的流程操作。
比如某次采购单的采购，当采购金额小于100万时需要采购经理即可进行审批，当大于100万时需要副总级别的人物进行审批后才可以进行。
并发流程与执行指的是多个流程共同执行，所有流角色程都执行完毕后才流转到下一个节点，比如某次项目的开始需要招商部，企划部，工程部共同完成。 只有当这些角色都审批完成了才能开始。
并发流程或执行指的是多个流程共同开始，只要有一个角色进行审批了，则流转到下一个节点。在此不做赘述。
在一般涉及到工作流的后台中，这几种情况大致就可以满足。
以上可以称之为标准工作流，即后台给予固定的模板，相关配置人员进行配置即可。但是，在有些复杂的后台系统中，可能是以上几种情况共同出现的，也可能是出现了其他情况，这个时候，就需要整体流程定制化的操作。
那么，要设计一个非标准工作流，首先是分清上文提到的角色、内容、流程之间的关系——即角色与内容是挂在流程节点上的功能点。所以我们只需要将流程节点控制好，再将不同的角色，以及对应的操作内容挂靠上去即可，这样一来是可以方便理清关系，另外也可以使系统更有层次。
所以接下来我们只需要将流程节点控制好即可 。
控制好非标准流程节点，可以由以下几个方面着手。
第一、如果流程配置者有配置SQL的能力，那么 将数据库流程配置权限开放，让配置者自行配置 ，这样的开发工作压力会小一些，但与此同时，风险也会很大。
第二、画流程图的方式 。一个流程的执行可以通过流程图来表现，对于产品经理来说是再熟悉不过了。通过流程图的基本逻辑，可以将流程中遇到的各种情况可视化的展示出来，条理清晰而且操作简单。缺点即开发难度过大，一般小团队难以胜任。
第三、通过一一配置功能来进行配置 ，这种方式虽然表面上看起来十分的繁琐，但是相对于前两种来说开发难度小，且对于配置者的能力要求不高。
具体来说，要单独配置每一项功能的流程，先确定流程的主流程有几个节点，如果碰到判断的节点选择是，碰到并发流程或执行的节点选择最长的一个流程。
确定之后，将所有节点的内容操作与角色配置出来，然后再配置该节点是否进行判断，是否进行或操作，是否进行与操作。
如果有判断操作时，则分出一个子流程，再将子流程按照上述方式进行配置，最终归于主流程的某一个节点。如果有与操作时，要确定配置与操作的分支节点时是要配置在单个节点还是多个节点。
单个节点的话则需满足这两个节点才往下进行，多个节点时则将这几个节点作为一个小流程单独按照上述方式进行配置再合并至主流程，看是否满足与行为。
如果有或操作判断时，同样要确定在哪个节点的或操作至哪个节点可以进行另外的节点流转。
以上这些情况对于开发团队来说也是一个巨大的考验，因为不同的工作流程代表着不同权限的操作，不同状态的流转，而可定制化的流程则代表着其中的变化无穷，对于服务器的压力，数据库的冗余情况都不容乐观。
接下来的部分，我会简单的分享一下如何才能高效的设计非标准工作流。
三、如何设计高效的非标准工作流
设计一个后台压力小，操作简单的高效非标准工作流，我总结了两个方式：第一、将非标准工作流拆分成多个标准工作流。第二、开辟独立与配置权限之外的工作流角色模块。
1. 将非标准工作流拆分成多个标准工作流
一个非标准工作流固然麻烦，可是在大多数的情况下，其可以拆分为几个标准工作流。比如，某个非标准工作流可以线性拆分为多个分支流程，并发流程与执行、并发流程或执行。
将其每一个组合到一起，即可形成完整的工作流，那么我们就可以在系统中提供组合模板，让配置者可以进行选择，组合到一起形成一个非标准工作流。
如果是非线性的，比如可能为分支套分支，并发套并发的情况，我们可以将每一种情况都拆分成一个工作流，然后将生产端入口保持统一，每一步的不同操作可以进入不同的工作流，最终流转的出口保持一致即可。有点类似于开发中设计模式的工厂模式。
2. 开辟独立与配置权限之外的工作流角色模块
一般来说，我们在配置工作流角色的时候，都是使用类似权限控制的角色，比如到这个节点角色为库管，另一个节点角色为商管。其实换个角度想想，再说设计工作流的时候，完全可以设计一个独立于权限之外只配置工作流的角色。
比如“分支节点角色1号”“流程角色1号”“并发或角色2号”，然后再通过穷举法，将所需要用到的使用流程都列出来，把角色放置于节点上。
这样，一个活的需要配置的流程就变成了一个个的死流程。
再将这些角色赋予权限角色。再定义一些规则：比如若没有配置此节点的角色则此节点默认通过，将某个工作流角色配置两个权限角色则为或操作/与操作。这样也就解决了上述的问题。
工作流可以说是后台 系统中比较复杂的一部分。即便某些系统中一开始没有工作流，随着系统功能的增加，也不可避免会用到工作流，所以提前了解下工作流的设计方法，对于产品来说很有帮助，在开始设计的阶段也可以考虑将内容设计进去以免后期维护成本过大。
