OA 审批流程为什么越加越长，以及怎么砍回去

几乎每个用 OA 超过五年的单位，都有一条审批链长得离谱的流程。最常见的是请假、报销、采购申请这三类。一条请假单要过七级审批，其中三个节点的审批人自己都不知道为什么要审。

问起原因，通常得到两种回答。一种说「制度规定的」，翻出制度一看，制度是五年前为了某次专项检查临时加的；另一种说「一直都这样」，没人说得清是哪一年加的。

流程膨胀不是某个人造成的，它有一套自己的机制。搞清楚这套机制，才知道从哪里下手。

一、为什么流程只会变长，不会变短

根本原因是加节点和删节点的成本极不对称。

加一个审批节点，成本接近零。系统里点几下，找领导口头同意，五分钟的事。而且加节点在组织里是「安全动作」——万一以后出了问题，可以说「当时是审过的」。

删一个审批节点，成本很高。要有人站出来说「这个环节没必要」，然后承担「万一出事」的责任。在多数组织里，没人愿意做这个决定。

于是流程就有了单向性：加容易，减很难。十年下来，长度不是设计出来的，是沉积出来的，跟河床里的泥沙一个道理。

二、三种典型病灶

病灶一：用审批节点转嫁责任

某个环节出了问题，追究下来，最常见的处理方式不是改流程逻辑，而是「再加一道审核」。这一道加上去，责任就被摊薄了——出问题时可以说「这一层也审过了」。

这种做法在短期内平息了问责，长期看是把风险控制变成了责任分散。每一层都以为自己只是「过一下」，结果没有任何一层真正在审。

病灶二：把「知会」做成了「审批」

很多节点的真实需求是「让某人知道这件事」，但在系统里被配成了审批节点。知会不占时间，审批要占时间——前者是消息，后者是卡点。

一个流程里如果有三个节点本该是知会、实际是审批，这条流程的平均耗时就会多出三倍以上，而这些节点从来不会驳回任何东西。

病灶三：例外变成了常态

某个金额以上要加一级审批，本来是为了控制大额支出。后来发现「金额以上」这条线定得太低，日常业务大部分都超过，于是这条例外通道变成了主通道。

这种情况在系统里的表现是：某个节点的审批量占了整条流程的八成，审批人每天点几十次同意，早就形成了「不看就点」的习惯。这时候审批已经完全失效，只剩形式。

判断一个审批节点还有没有实际作用，看一个数就够了：这个节点的驳回率。长期接近零的节点，不是在审批，是在签收。

三、判断一个节点该不该留：三个问题

不用一上来就谈流程再造，先从单点判断开始。对每一个节点问三个问题：

第三个问题最有价值。很多审批节点做的事情，本质是核对几项数据是否齐全、金额是否在预算内、附件是否符合要求——这些是规则能做的事，不需要人来判断。把这类节点改成系统自动校验，流程立刻短一截，而且校验得比人更准。

四、重构时最容易犯的错：想一次砍到位

看到流程太长，很多单位的第一反应是做一次彻底梳理，把所有节点重新设计一遍，然后一次性上线。

这条路通常走不通，原因不在方案质量，在组织的接受度。一次性砍掉大量节点，意味着同时改变了多个部门的工作习惯和权责边界。任何一处出问题，都会有人提出「还是恢复原来的流程稳妥」，然后整个方案被推翻，连带那些本来正确的改动也一起退回。

更可行的做法是分批推进，每一批控制在「能让用户感知到变快，但不至于让人不安」的范围内：

1. 第一批只做知会降级。把那些从不驳回的审批节点改成知会。这一步几乎没有阻力，因为没有人失去权力，但流程耗时立刻下降；
2. 第二批做规则校验替代。把「核对事实」类的节点交给系统。这一步需要梳理校验规则，工作量大一些，但争议小；
3. 第三批再动真正的审批结构。到这一步，前两批已经证明流程可以更短，讨论的氛围会健康很多。

五、一个更根本的问题

流程变长，很多时候不是流程设计的问题，是制度本身没有跟上业务变化。制度是五年前定的，业务早就变了，但没人去改制度，只在系统里加节点来应付新情况。节点越加越多，本质是制度欠账在系统里的体现。

所以真正的解法往往不在 OA 里。流程梳理做完之后，得有人拿着梳理结果去改制度文本。这件事通常需要办公室或者综合管理部门牵头，IT 部门推不动。

如果这一层推不动，那流程优化就只能做到「系统里的节点少了」，过一两年又会慢慢加回来。这不是技术问题，是管理问题，得说清楚。