审批流

1. 3 秒看懂

审批流是把组织内的“谁、在什么条件下、按什么顺序、用多长时限”来批准或驳回一项业务申请这一整套决策过程，固化为可追溯、可回退、可审计的数字流程。它的表面是表单和按钮，底层是状态机、权限快照、事件驱动和事务补偿的精密组合。一句话：审批流就是数字化之后的责任链与决策路径。

2. 3 分钟产业解释

每个打工人都用过的请假、报销、合同盖章、采购申请，背后都跑着一条审批流。和随口一句话的“行不行”完全不一样，审批流必须严格遵从组织权限和业务规则：

1. 表单承载数据（请假天数、报销金额）触发流程引擎。
2. 流程引擎解析模型（BPMN 图或状态机定义），找到当前应该停在哪个节点、谁该审批。
3. 按照规则匹配审批人（部门负责人、财务总监，可能是静态指定，也可能是实时计算组织树），生成待办任务。
4. 审批人操作（同意、驳回、加签、转办、委托、前加签/后加签），引擎记录操作日志并移动流程节点。
5. 所有强制节点通过后流程结束，回调业务系统（更新订单状态、放款、记账）。

在产业一侧，审批流早已不是 OA 里的一个独立模块，而是低代码平台、PaaS/SaaS、RPA、BPMS（业务流程管理套件）的内核级能力。企业选型时不再只看“能不能批”，而是更关心：流转有多灵活（会签、或签、动态加签）、能否嵌入已有系统、高并发下状态是否一致、跨组织审批时法律证据链是否完整。

3. 技术原理

审批流本质是一套基于有向图模型的分布式状态编排系统，其运行时由三层核心组件协同：

• 流程定义模型：描述节点、连线、网关、定时事件的静态元数据，常用 BPMN 2.0 XML 表达。
• 流程实例运行时：每张业务单据创建一个实例，持有当前节点指针、上下文变量（表单数据快照）、审批历史栈和流程版本号。
• 任务管理服务：生成任务、推送待办中心、校验操作权限、记录操作日志、更新实例状态并触发后续节点。

执行机制（简化示例）

 发起人提交
     │
     ▼
 入口网关（条件分支）
     │
     ├─[金额 ≤ 5 万]──► 部门经理审批 ──[通过]──► 实例状态=完成
     │                                 ──[驳回]──► 实例状态=已驳回（可配置回退节点）
     │
     └─[金额 > 5 万]──► 部门经理审批 ──[通过]──► 财务总监审批（会签，需 ≥2 人通过）
                                                    │
                                              [全部通过]──► 完成
                                          [任一驳回]──► 已驳回

真正的复杂性藏在几个常被忽略的层次里。

状态机层 每个实例的状态必须严格一致且可回溯。典型状态模型包含：未提交、审批中、已通过、已驳回、已撤回、已终止。复杂场景还有子流程挂起、超时自动流转、管理员强制干预（实例跳转）等状态，这些都要求引擎能妥善处理状态迁移的合法性，避免出现“既通过又被驳回”的矛盾。

网关与分支求值 条件表达式（如 amount > 100000 AND costCenter == "研发"）通常使用 FEEL、SpEL 或自定义脚本语言在运行期动态解析表单字段与上下文变量。这一步既要保证执行效率，又必须防范注入风险，因此企业级引擎多采用受限语法或解析器沙箱。

上下文与权限层 审批人在不同节点看见的数据视图并不相同——某些字段需要脱敏、隐藏或只读。操作权限（同意、驳回、仅加签、仅填写意见）也需要动态计算，通常由表单引擎与权限服务协同完成，而非硬编码在流程定义中。

时间与事件层 定时边界事件（如 24 小时未审批自动升级给上级）、条件事件（金额 >10 万自动触发合规审查节点）依赖流程引擎支持事件子流程与定时器，并能在分布式环境下准确触发，不丢失、不重复。

集成与 Saga（长事务补偿） 审批通过后往往还需要调用支付、库存、CRM 等多个外部系统。如果“审批已通过”但后续外部调用失败，就会出现业务不一致。成熟的审批流方案必须引入补偿机制（Saga 模式），例如记录失败任务，逆向调用已执行的外部操作，或将流程挂起到人工干预队列。

高并发一致性 两人同时审批同一节点、管理员强制干预与正常审批并行、流程版本热更新（升级定义但不影响已运行实例），这些都需要谨慎的并发控制。常用手段是实例版本号乐观锁，或基于 actor/cell 模型将同一实例的所有操作路由到单线程执行，从而避免分布式锁的开销。企业级引擎还需支持组织架构实时变动时的审批人快照一致性——审批启动时是按当时的组织关系冻结审批人，还是每次都实时计算？不同策略对业务影响极大，必须在设计上明确。

理解这些之后，才能明白为什么审批流不是“填个表单、打个勾”这么简单。它是以有向图、状态机、事件和时间为核心，把人的决策过程变成可编程、可追踪、可补偿的系统。

4. 关键参数

以下参数衡量审批流引擎是否达到企业级水准，数字标记“公开资料未见”表示该指标因高度依赖部署环境而未形成行业统一基准，具体应结合厂商性能测试报告判断。

• 流程定义复杂度上限：最大节点数、网关嵌套深度、循环嵌套层数。企业级引擎通常支持单图数千节点而不出现解析劣化；公开资料未见统一上限标准。
• 吞吐量：引擎每秒可推进的流程实例状态迁移数。在事件驱动或 actor 模型实现下，单节点可达数千 TPS（来源：Camunda 等开源引擎基准测试，具体数值随版本和硬件变化，建议查阅官方基准）。
• 端到端响应延迟：从审批人提交决策到实例状态持久化、下一节点任务生成的总耗时。核心受状态持久化写操作（数据库或事件日志）延迟影响，通常要求 P99 < 200 ms（企业内部参考值，公开行业标准未检索）。
• 任务签收与操作幂等性：审批操作必须支持幂等，网络重试不会导致重复审批或流程跳变。此指标用异常率衡量，目标应接近 0。
• 流程版本在线热更新兼容率：升级定义后，运行中实例平滑迁移（不丢失、不重复节点）的百分比。企业场景要求达到 100%，否则需停机迁移，但公开资料未见各厂商实测数据。
• 组织快照一致性：流程启动时审批人链路的冻结方式（快照/实时计算）以及变更后对运行中实例的影响范围。无通用量化指标，但直接决定跨组织变动时的稳定性。
• 资源争用和线程池饱和度：乐观锁冲突重试次数、线程池排队长度等，反映并发瓶颈。需由运维侧结合业务量监控。

5. 技术路线

审批流的技术实现路线并非单一路径，实际产品常是多种路线的组合。下表对不同路线进行定性对比。

注：★ 为定性评级，5★最高；各产品能力可能因版本迭代快速变化。部分路线在实践中常以混合形式出现，比如低代码平台底层嵌入 BPMN 引擎，或智能审批叠加在状态机之上。

6. 上游

审批流的上游决定了它“能不能把任务发给对的人、看到对的数据、用对的条件分支”。任何一个上游环节的延迟或数据错误都会直接导致流程下发的错误。

• 组织架构与身份认证服务：通常对接 LDAP / AD / HR 系统，为流程提供部门树、岗位、汇报关系。这是动态审批人计算的基础，服务不可用将导致所有流程无法生成任务。
• 动态表单渲染引擎：提供审批时看到的数据视图、字段权限（可见/不可见/可编辑）、前端校验规则。表单与流程的深度绑定使得两者常为同一平台基础设施。
• 规则引擎：决策表、Drools 或 FEEL 规则，用于条件分支求值与自动决策。复杂网关需要规则引擎快速解析，部分场景会独立部署规则服务。
• 消息队列/事件总线：审批流转过程中产生大量事件（任务生成、审批提交、流程完成），用于异步通知下游，避免同步耦合。队列堆积或丢失会直接影响实时性。
• 企业缓存/快照服务：为隔离上游组织服务偶发抖动，审批流引擎常用缓存存储启动时的组织关系快照，确保流程启动后不受组织结构变动影响。

典型的 SLA 要求：上游身份认证服务可用性 ≥ 99.9%，规则引擎 P99 延迟 < 20 ms，以确保审批流端到端体验。

7. 下游

审批流的下游是它“做完决策之后还要做什么事”的环节，也是业务价值的最终实现点。

• 统一待办任务中心：将来自不同系统的审批任务聚合到一个界面，支持待办已办、批量审批、移动端消息推送。这是终端用户的主要接触点。
• 业务系统回调：ERP / CRM / SCM / 费控等系统在审批完成后更新单据状态、放款、发货、记账。回调失败需要有重试和补偿机制。
• 档案与合规系统：审批记录、操作日志、附件需要归档至档案系统或电子存证平台，满足审计、法务要求。部分行业还需对接电子签名服务（如 e签宝、法大大）。
• BI 与流程挖掘：审批时长、驳回率、节点瓶颈等数据被导入分析平台，用于组织效能诊断。流程挖掘工具（如 Celonis）可直接从事件日志重构实际流程模型，发现与设计模型的偏差。
• RPA 自动化机器人：审批通过后，RPA 可代替人工完成后续系统间的数据搬运（例如从 CRM 复制合同信息到 ERP 建账），减少人工操作，但同时增加了整体流程一致性管理的复杂度。
• 即时通讯与协作工具：审批通知通常通过钉钉、飞书、企业微信等 IM 渠道实时推送，并允许在对话中直接完成审批，减少应用切换成本。

8. 受益公司

审批流作为一种基础能力，很少单独作为产品出现，通常是嵌入在 OA、低代码平台、BPMS 或云服务中。以下按模式分类列举受益方向和典型公司（仅用于产业分析，不构成投资建议，财务数据请以各公司最新年报为准；若无公开拆分数据，明确注明“公开资料未见”）。

开源/PaaS 引擎商业化

• Camunda：核心引擎开源，提供云托管服务（Camunda SaaS）。其赞助商模式与 BPMN 标准深度绑定，在微服务编排和审批流中都广泛应用。公开资料未见针对审批流部分的独立营收拆分。
• Flowable：由原 Activiti 核心开发者创建，开源基础上提供企业版与云服务。开源社区活跃，常被国内厂商作为底层引擎集成。

企业软件厂商

• SAP：S/4HANA 和 SuccessFactors 内嵌审批工作流，深度连接财务、HR 和供应链，审批流是其平台用户粘性的重要部分。不单独拆分审批流收入（公开资料未见）。
• 用友网络：BIP 平台和 NC Cloud 中审批流属于基础能力，服务于大量中大型企业客户。未披露审批流单独模块收入（公开资料未见）。
• 金蝶国际：金蝶云·星瀚、苍穹平台包含审批流引擎，不单独披露审批流收入（公开资料未见）。

平台级嵌入

• ServiceNow：ITSM 与审批流深度结合，Flow Designer 提供可视化审批编排，面向大型企业。其订阅收入中审批流作为工作流的一部分，无法单独拆分（公开资料未见）。
• Salesforce：Approval Process 引擎内嵌于 Sales Cloud / Service Cloud，为销售、服务流程审批提供支撑。不单独披露审批流收入。
• 微软 Power Automate：作为 Power Platform 成员，提供审批连接器与自动化审批流，以订阅和用量计费，与 Office 365 深度绑定。

国内协作/OA 生态

• 泛微网络：OA 龙头，审批流是产品核心，长期积累大量政企客户的复杂审批模板。公司整体营收可在年报查阅，但审批流单独贡献未披露（公开资料未见）。
• 致远互联：协同办公及审批流能力覆盖中大型组织，同样不单独拆分审批流收入。
• 钉钉、飞书、企业微信：均提供免费基础审批，作为获客与促活手段，通过专业版/OA 版/aPaaS 高级能力收费。审批流的使用频次与次日留存高度相关，是这些平台的关键粘性模块。各家不披露审批流单独贡献收入（公开资料未见）。

新兴方向

• AI 辅助审批：部分初创公司尝试用 NLP 解析合同风险、自动生成审批意见，辅助财务审核等场景。多数处于早期融资阶段（如 Seed~A 轮）。
• Web3/多签钱包审批流：基于智能合约的多签审批，用于 DAO 资金管理，但企业大规模采用仍有距离。

9. 市场规模

截至 2025 年 4 月，公开资料未见针对审批流独立细分市场的定量规模统计。审批流市场价值通常嵌入在更大范畴的流程自动化（BPM）与低代码/无代码平台市场中，且各研究机构的口径差异较大。

• 流程自动化市场：据 Gartner 等机构近年报告，全球业务流程管理（BPM）和超自动化（Hyperautomation）软件及服务市场处于数百亿美元量级，并保持双位数增长。具体年度数字请参阅 Gartner 发布的《超自动化市场预测》或 IDC 相关追踪报告。
• 低代码/无代码市场：Gartner 预测 2024 年全球低代码开发技术市场约达 XXX 亿美元（因报告获取限制，此处不转载具体数字，详见 Gartner 官方发布），其中审批流、工作流与表单是核心组件，常被列为关键用例。
• 中国市场：中国信通院及多家分析机构的低代码/无代码市场报告中，审批流/流程自动化被视为数字化基础能力，市场保持较快增长。具体规模数据建议查阅信通院《低代码发展研究报告》最新期数。

审批流是“无处不在但难以独立计费”的能力，因此评估其市场规模需关注相关平台的整体 ARR 或订阅收入增长，以及流程自动化渗透率指标。

10. 玩家对比

以下对比聚焦于主流审批流引擎/平台的代表性模式，维度涉及架构开放性、复杂流程支持、部署模式、社区生态和典型客户画像。均不涉及具体营收数字，因为“公开资料未见”统一的拆分口径。

注：上述对比基于公开产品文档与行业认知，功能细节随版本更新变化，建议参考各厂商最新白皮书。

11. 风险

审批流自身及依赖其运行的业务面临以下风险，产业参与者在选型和架构设计时需持续评估。

• 竞品同质化与免费化压力：基础审批功能门槛极低，钉钉、飞书、企业微信等以免费审批拉新促活，使独立 OA 厂商和中小型引擎的生存空间受到挤压。缺乏差异化能力（如合规存证、AI 辅助决策）的厂商可能面临价格战与客户流失。
• 性能与可用性风险：审批流是大量核心业务（报销、合同、付款）的阻塞点。流程引擎自身出现性能瓶颈、死锁、并发冲突导致大面积审批卡顿，可能直接中断业务运转。此类风险在超大型组织高并发期（如月底报销高峰）尤为突出。
• 组织数据依赖与迁移锁定：审批流深度绑定组织架构、权限和表单，一旦上线，迁移成本极高（包括历史流程实例、审计日志、用户习惯），供应商锁定效应明显。这会限制企业后续议价能力和架构选择。
• 合规与证据链缺陷：金融、医药、政府等行业对审批留痕、电子签名、不可篡改有时间戳的要求。若系统未提供合规存证或审计日志不可追溯，企业将面临监管罚款或法律争议风险。
• 安全与权限失控：动态审批人计算若存在权限绕过漏洞（如越权审批、参数篡改），可能导致资金损失或数据泄露；表达式注入漏洞（如 SpEL 注入）可被利用执行恶意代码，属于高危风险。
• 长事务一致性设计缺陷：不少自研或轻量审批流未设计完善的 Saga 补偿机制，在审批通过但后续业务执行失败（如支付失败、库存扣减失败）时遗留数据不一致状态，修复成本高、业务影响大。

12. 误读纠偏

误读 1：审批流就是工作流 工作流范围更广，涵盖自动化、人工、集成、消息等多种任务编排；审批流特指需要人工决策的核签型流程，且非常强调责任归属、回退与加签操作，在 BPMN 标准中属于“用户任务”及围绕它的特定模式。把两者等同，会忽略审批流在权限、快照和证据链方面的额外要求。

误读 2：审批流必须是线性串行的 许多实际业务是并行的（多人会签、或签）、动态的（根据金额增加审批节点），成熟的审批流支持并行分支、条件跳过、子流程、动态加签，远非“一个人过了下一个人”这么简单。低估其路由能力，就会设计出僵化流程，反而降低效率。

误读 3：审批通过后就万事大吉 审批的原子操作和后续业务执行之间存在分布式事务间隙。需要补偿机制处理“审批已生效但支付/发货失败”这种部分执行场景。没有此设计的系统，最终会积累大量业务不一致的“悬空”记录，手工修补代价极高。

误读 4：有了低代码审批，就不需要引擎概念 低代码平台封装了大部分复杂性，但如果业务需求超出平台预置模板（例如需要复杂 Saga 补偿、跨公司审批存证、事件子流程），就必须理解底层引擎的工作原理。把低代码当作万能钥匙，遇到复杂场景就容易撞墙。

13. 最新事件

截至 2025 年 4 月，公开资料未见审批流领域足以单独构成行业里程碑的单体事件，但以下产业动向作为日常演进值得关注（均为公开信息摘要，建议查阅厂商官方渠道获取细节）：

• Camunda 持续增强云原生与 AI 能力：Camunda 在近年版本更新中强化了多租户隔离、流程实例热迁移，并开始引入 AI 驱动流程推荐。（来源：Camunda 官方博客）
• 国内低代码审批平台持续迭代：钉钉、飞书审批模块在 2024–2025 年间陆续升级了跨组织审批、与电子签名更深度集成，以及连接器生态扩展。（来源：各平台更新日志）
• AI 审批助手趋势加速：多家 SaaS 厂商和独立开发者已推出利用大语言模型（LLM）辅助审批意见摘要、合同风险提示的功能，但仍处于早期产品化阶段，尚无大规模基准数据披露。（来源：网络公开报道）
• 《电子签名法》等法规执行强化：中国持续提升电子合同和审批留痕的法律效力要求，促使更多审批流产品内建存证与时间戳服务。（来源：国家政策文件）

14. 跟踪指标

监控审批流运转健康状况和业务价值，应关注的指标如下（建议结合具体厂商的管理控制台进行量化）。

• 流程流转正确率：成功到达终点的实例占全部到达终态的实例比例，目标接近 100%。因流程定义缺陷导致的“死流程”比例需独立监控。
• 节点平均审批耗时：从任务生成到审批人提交决策的时间（可剔除节假日），常用来定位瓶颈岗位和流程节点。
• 端到端流程时长 P50/P95：从发起到最终结束的业务视角耗时，能暴露长尾异常（频繁驳回、多人加签）带来的延迟。
• 审批操作可用性：签收、提交等核心操作的业务异常率（不含审批人主动驳回），反映引擎及依赖服务的稳定性。
• 流程版本在线迁移兼容率：升级流程定义后，存量运行实例成功平滑过渡的百分比，目标应为 100%。
• 资源争用指标：乐观锁冲突重试次数、任务队列深度、线程池使用率，反映引擎在业务峰值下的并发瓶颈。
• 人工干预频率：管理员强制干预（如跳转、撤回、重新指定审批人）的次数，频率升高可能意味着流程设计或组织数据异常。
• 用户触达与完成率：待办消息推送成功率、移动端审批完成占比，可衡量审批流的体验质量与办公移动化程度。

15. 信源

• 工作流管理联盟（WfMC）术语表及参考模型（公共标准）
• OMG 规范：BPMN 2.0 Specification
• Marlon Dumas 等《业务流程管理基础》（Fundamentals of Business Process Management）
• Camunda 官方文档：工作流引擎架构与审批模式
• Flowable 开源文档与用户指南
• 阿里云、AWS 平台上审批工作流最佳实践白皮书（供应商案例）
• Gartner：《超自动化市场预测》《低代码开发技术魔力象限》（各年报告，具体期数以官方发布为准）
• Forrester Wave：Low-Code Development Platforms（定期更新）
• 中国信通院《流程挖掘研究报告》《低代码发展研究报告》
• 各厂商官网及产品更新日志：钉钉开放平台、飞书开发者文档、ServiceNow 产品文档、微软 Power Automate 文档、泛微网络、致远互联

注：因未进行本次环境下的实时信息检索，所有定量数据均标注为“公开资料未见”或不转载具体数字，技术性能数据建议查阅各自官方最新基准及学术文献。本文所有内容不构成任何投资或选型建议。