Ezpay

审批流做得好不好，平时看不出来，出问题时却很明显：单子卡在某个节点无人处理，同一件事走了三种不同路径，审计时说不清依据在哪一条规则。多数审批流的问题不是系统能力不够，而是设计阶段就没把责任、条件与例外想清楚。以下五条原则，是从大量流程配置中沉淀下来的判断标准。

一、原则一：节点跟着责任走，不跟着职级走

很多审批流把审批链按职级一路排上去：主管、经理、总监、副总，逐级会签。看似严谨，实际造成大量无意义的点击——不掌握信息的层级只能凭印象签字，责任反而被稀释。合理的做法是先问“这件事需要谁来判断”，再定节点。金额超限需要财务复核，是责任；技术方案变更需要技术负责人确认，是责任；而“领导都该知道”，通常只需要知会，不必设成审批。

1.1会签不是越多越稳

会签适合需要多方共同承担责任的场景，比如跨部门制度发布。若把会签当作免责手段，节点越多，流程越慢，真正该负责的人越模糊。

1.2知会与审批要分开

系统里“需审批”和“需知晓”是两种不同的动作。把知会设成审批，等于让不掌握信息的人替别人做决定；把审批降为知会，则等于放弃了把关。

二、原则二：分支条件要写成可判定的事实

流程分支的常见写法是“重大事项报总经理”，问题在于“重大”由谁判定。条件若不能落到具体字段，执行时只能靠人解释，同一类事项在不同人手里走出不同路径。可判定的条件通常具备两个特征：取自表单字段，有明确阈值或选项。金额、类型、所属单位、是否涉及外部合同，这些都能判定；“情况特殊”不能。

2.1条件要穷尽

设计分支时，除了正常情形，还要写明都不满足时走哪条默认路径。缺少默认分支，流程在某些组合条件下会无路可走，只能由管理员手工干预。

2.2条件要可维护

阈值会调整，组织会变化。把条件写进可配置的规则表，而不是硬编码在流程里，改动时才不必重新发版。一条审批流若每次调整都要走技术排期，业务端就会倾向于绕过它。

三、原则三：一条流程只办一件事

把采购申请、合同会签、付款审批串成一条大流程，看起来省事，实际使用时却处处别扭：某一单只需要改付款账号，却要重新走一遍采购与合同环节；某个环节退回，整条流程从头再来。流程越长，例外越多，维护成本呈指数上升。合理的方式是按事项拆分，用子流程或流程调用串联，各段独立可追溯。

3.1拆分的判断标准

一件事是否有独立的触发条件、独立的责任人、独立的结果输出。三者具备，就应当独立成流程。

3.2集团场景下的子流程

总部与分子公司对同类事项的管理口径不完全一致时，用子流程承载各单位差异，主流程保持统一。这样既保留了统一管控，也容纳了本地做法。

四、原则四：异常路径与正常路径一起设计

正常路径通常只有一条，异常情形却有很多：审批人休假、岗位空缺、意见不一致需要加签、材料不全需要补正、超时无人处理。这些情形若在设计时没被考虑到，上线之后就会变成电话沟通与线下特批，流程的严肃性随之瓦解。

4.1代理人机制要提前配

休假与出差是常态。代理关系应支持按时间段设定、自动生效、到期回收，并在流程记录中标注由谁代行，避免事后争议。

4.2退回要说清原因

退回时要求填写具体问题与修改建议，退回意见进入流程记录。只点“不同意”而不写理由，会让发起人反复试错。

4.3超时要有人兜底

超时提醒只能解决一部分问题。超过约定时限仍无人处理的事项，需要有明确的升级规则：转交上级、转交代理，或由流程管理员介入。没有兜底的审批流，久而久之就会演变成发起人手动催办。

五、原则五：流程必须能被度量

流程上线不是终点。哪一类单据平均停留时间变长，哪个节点退回率偏高，哪个部门积压占比高，这些数据决定了流程还能不能继续优化。设计阶段就要预留度量口径：节点进入与离开时间、退回次数、加签次数、代理处理占比。没有这些记录，流程改进只能靠感觉。

度量还有一个附带作用：让流程的合理性可被讨论。当一个节点长期只做形式性点击，数据会把它暴露出来，撤并节点也就有了依据。这比靠一次流程梳理会议去争取，要有效得多。反过来说，若一套审批流上线半年，拿不出任何关于时长与退回的统计，那么所谓优化就无从谈起，只能等下一次有人抱怨时再临时应对。

六、原则之外的工程细节

版本管理不可省：流程调整后，在途单据应按原版本继续走完，新单据使用新版本，否则历史记录会失去解释力。权限与日志同样重要，谁改了流程、何时生效、影响了哪些在途单据，都应当留痕。流程若需与业务系统交互，还要考虑接口的稳定性与失败重试，避免因外部系统不可用导致单据长期挂起。

审批流设计的功夫，多半花在上线之前：把责任分清、把条件写实、把例外想全。这五条原则不复杂，难的是在设计时愿意多问几句“这种情况怎么办”。问得越多，上线后的特批越少。