审批流程做进系统之后，最常见的抱怨是又要改。改一次要走一轮开发、测试、上线，一年下来流程改动的成本可能比系统本身的建设费还高。
流程频繁变动，一部分是管理本身在调整，这个没法避免。另一部分是设计方式的问题，本来可以不用改代码的，被做成了必须改代码。分清这两类，能省下大量重复投入。
一、规则和节点要分开
很多系统把规则写死在节点里。比如分管领导审批这个节点里，直接写了一句如果金额大于两万则通过。金额阈值改了，就得改这个节点的代码。
更好的做法是把规则抽出来，做成一张条件表。节点只负责一件事，即满足什么条件时轮到谁审。条件表里可以配置字段、比较方式、阈值。这样金额从两万调到三万，改一条配置记录就行，不用碰程序。
抽出来之后还有个附加好处，谁能改配置就成了一项可以分配的权限。业务部门自己就能调整阈值，不必每次都找开发方。当然前提是留下一份变更记录，谁在什么时候把阈值改成了什么。
二、审批层级要能增删，不能写死
把三级审批写死在程序里，将来要加一级就得改结构。这类问题在组织架构调整时特别常见，部门合并了、岗位新设了，流程跟着要变。
做法是把审批层级做成数据。每个流程定义里有一组节点，节点有顺序、有审批人来源、有会签还是或签的属性。加一级就是加一条节点记录，顺序重新排一下。
审批人的来源也要灵活。常见的有几种，指定具体人、按角色找人、找申请人所在部门的负责人、找发起人的直属上级。设计的时候把这几种做成可选项，后面遇到新情况时，多半能在已有选项里找到，不用新增逻辑。
三、流程要能带版本
流程可以配置之后，会出现一个新问题，正在流转中的单据怎么办。流程改了，是让在途单据按新流程走，还是继续按老流程走完。
比较稳妥的做法是流程带版本。单据在发起的时候，记录当时用的流程版本号。后面流程改了，旧版本不影响在途单据，新发起的单据用新版本。这样改动就不会打断正在办的事。
带版本还有助于事后追溯。查一笔半年前的审批，能看到当时的流程长什么样、谁审的、为什么是这个顺序。不带版本的话，半年前的单据配上现在的流程图，是解释不通的。
四、哪些改动真的避免不了
有一种改动是设计再灵活也躲不过的，就是审批环节本身的增减，比如新设了一个部门必须参与审批。这类属于管理决策层面的变化，系统跟着调整是正常的。
能减少的是另一类，就是同一件事反复摇摆。今天要求金额超过一万要审，下个月改成两万，再过两个月又改回一万。这类反复往往说明规则制定本身没有想清楚，跟系统无关。
碰上这类情况，建议把改动的影响量化给对方看。改一次需要多少工时、涉及哪些测试、在途单据怎么处理。把这些摆出来，规则制定方往往会认真一些，不至于随意调整。
下一篇换系统时旧数据怎么迁移