AAIPROS

AIPROS · Static Essay Page

有了 AI,就不需要 OA/BPM 了吗?

组织转型 公众号文章 2026-05-30 5 min

他们内部有大量审批流,所以对 AI 审批、智能审批、流程智能体都很关心。

有了 AI,就不需要 OA/BPM 了吗?一次审批交流后的 9 个判断

最近和一家大型科技公司的产品团队聊审批。

对方是看了我的文章后联系到我的。

这件事本身很有意思。

他们内部有大量审批流,所以对 AI 审批、智能审批、流程智能体都很关心。

但聊着聊着,我发现一个更重要的问题。

很多人不是不知道 AI,而是不够理解审批。

更准确地说,是没有把审批流、审批责任、OA/BPM、AI 判断这几件事分开。

一旦混在一起,产品就容易做偏。

比如,对方问了一个很典型的问题:

既然有了 AI,是不是就不再需要 OA 或 BPM 了?

我的回答很明确。

不是。

审批引擎是审批引擎,AI 是 AI。

两者可以配合,但不能互相替代。

审批不是一个聊天建议。

审批是一条授权链。

谁发起,谁补充,谁会签,谁退回,谁同意,谁最终承担责任,都要被系统记录下来。

如果把 BPM 拿掉,流程在哪里实现?

权限在哪里判断?

状态在哪里流转?

审计在哪里回放?

这些问题没有回答清楚,AI 越强,风险越大。

一、先把一个误区说清:AI 不会天然替代 OA 和 BPM

真正的问题不是“AI 能不能批”,而是“AI 凭什么批”。

OA 和 BPM 的核心,不是表单好不好看。

它们真正承载的是组织授权、流程状态、权限边界和审计记录。

这也是为什么 BPMN 会成为长期存在的流程表达标准。

根据 OMG 和 ISO 对 BPMN 的定义,它要解决的就是业务流程在不同视角、不同工具、不同组织之间如何被标准化表达。

换句话说,流程不是为了让人多填几张表。

流程是组织把“谁可以做什么决定”固化下来。

AI 可以读材料,可以提建议,可以生成审批意见。

但 AI 不能凭空获得组织授权。

如果一个采购审批本来需要业务负责人、财务、法务共同确认,AI 给出“建议同意”并不等于组织完成了授权。

它只是提供了判断材料。

真正的审批动作,仍然要落在流程引擎、权限体系和责任链上。

二、工作流不会消失,它只会从“表单流”变成“判断流”

工作流不会因为 AI 出现而消失,真正会消失的是低价值的人工搬运。

今天很多审批让人痛苦,不是因为有流程。

而是流程里夹杂了大量无意义动作。

下载附件。

翻合同。

查预算。

复制历史意见。

问前一个节点为什么这么填。

这些动作会被 AI 大量接管。

但“流程”这件事不会消失。

因为企业仍然需要状态,需要边界,需要责任。

未来的工作流更像一个带判断能力的协同空间。

表单不再只是字段集合。

每个节点都会带着上下文、风险提示、历史相似案例和可解释建议。

人不再从零开始看材料。

人会站在 AI 已经整理好的判断台上,做最后取舍。

三、AI 审批最难的不是模型,而是审批上下文

没有上下文的 AI 审批,只是在审批页旁边放了一个会聊天的备注框。

很多人以为 AI 审批就是把表单字段丢给大模型。

这太乐观了。

真正的审批判断,往往不在表单里。

合同主体是否一致,要看合同、客户档案、开票主体和历史交易。

账期是否异常,要看付款条款、客户等级、回款记录和同类合同。

费用是否合理,要看预算池、项目阶段、历史消耗和业务解释。

这些数据散在不同系统里。

有的在附件里。

有的在历史审批意见里。

有的在业务人员脑子里。

所以 AI 审批的第一件事,不是训练一个更会说话的模型。

而是把审批上下文建出来。

谁是主体,交易是什么,风险在哪里,过往怎么批,例外怎么处理。

这些信息不被组织化,AI 就只能猜。

四、AI 参与审批,至少有三种产品形态

不要先争论“独立平台”还是“嵌入系统”,先看 AI 到底站在哪个位置。

我现在看到的 AI 审批,大致有三种形态。

第一种,是审批页旁边的侧边栏。

人打开审批单,旁边出现 AI 建议。

它适合低改造、快上线。

缺点是容易变成“旁观者”,只能给建议,不能真正进入流程动作。

第二种,是消息监听型智能体。

审批消息来了,智能体读取表单和附件,生成意见,必要时推给审批人确认。

它更像一个数字同事,适合高频、规则相对稳定的场景。

第三种,是浏览器插件或入口增强。

员工打开审批页,AI 自动识别页面内容,调用规则库和外部数据,给出判断。

这种方式适合存量系统多、短期不方便深度改造的企业。

但我现在更倾向于做第四种。

不是把 AI 塞进旧页面。

而是重新设计审批入口。

左边是对话,右边是 Canvas 看板。

对话负责追问和解释。

五、低代码不是不行,但别把它当组织级审批引擎

低代码适合快速搭表单,不一定适合承接企业级授权链。

交流里也谈到一个问题。

能不能直接用低代码平台做 AI 审批?

我的判断比较保守。

轻量申请、部门内部流转、临时数据收集,可以做。

但一旦涉及组织级审批,就要非常谨慎。

组织级审批需要稳定的权限体系、状态机、流程版本、异常回滚、代理人机制、日志追踪和审计回放。

这些能力不是把几个页面拖出来就解决了。

更麻烦的是流程版本。

同一个采购申请,上个月走一版规则,这个月走另一版规则。

审批走到一半,组织架构变了,审批人调岗了,节点规则调整了。

旧单据按旧规则走,还是按新规则走?

这些问题很细,但都是审批系统的硬骨头。

如果底座不稳,AI 只会把不稳定放大。

六、自动审批要分级,不能一上来就让 AI 点“同意”

自动化不是一个开关,而是一条从辅助到授权的坡道。

我更建议企业把 AI 审批分成几个等级。

L0,是纯人工。

AI 不参与,只是人看材料、人写意见。

L1,是信息整理。

AI 帮你读附件、提字段、找缺失项。

L2,是风险提示。

AI 告诉你哪里异常,为什么异常,参考了哪些规则。

L3,是辅助审批。

AI 生成建议意见,人做最终决定。

L4,才是低风险自动执行。

前提是规则清楚、数据可靠、错误成本低、过程可回放,并且组织已经认可责任边界。

多数企业一开始不该冲 L4。

先把 L1 和 L2 做扎实,就已经能释放大量时间。

七、真正难的部分,往往不是厂家能卖给你的模块

厂商能交付工具,企业要自己沉淀判断标准。

我听过一些 AI 审批助手方案。

报价不低,能力也不差。

但问题是,产品模块只是外壳。

真正难的是厂家很难替你解决的部分。

比如,规则怎么梳理。

同一类审批,历史上为什么有人同意,有人退回,有人要求补充材料?

比如,上下文怎么构建。

哪些系统必须接,哪些字段有可信度,哪些附件必须读,哪些历史意见应该进入提示?

再比如,版本怎么解析。

规则改了以后,旧单据怎么解释,历史判断怎么复用,模型建议怎么审计。

这些不是买一个按钮就能解决的。

所以我一直认为,企业做 AI 审批,不一定要迷信大而全平台。

先做一个可控场景。

把规则、数据、提示、人工确认、日志闭环跑通。

通用产品做到 75 分,你能做到 81 分,就已经赢了。

八、下一代审批入口,可能不是嵌入,而是重做

不要只想着把 AI 插进旧页面,也可以让审批页面本身变成智能体工作台。

我之前设计过两类类似产品。

当时主要想的是嵌入。

我提供前端组件,对方集成进现有审批页。

实践下来并不轻松。

每个企业的页面不一样。

每个系统的接口不一样。

每个审批节点的动作也不一样。

所以我最近在重新想一个更完整的形态。

员工进入审批时,不再面对一个孤立表单。

而是进入一个智能体界面。

左边可以对话。

右边是 Canvas 看板。

看板里有审批单、附件摘要、风险点、规则命中、历史相似单据、建议意见和可执行按钮。

你可以问:

“这个合同主体有没有问题?”

“为什么建议退回?”

“帮我生成一段审批意见。”

“把这张单据转给财务复核。”

AI 负责理解和组织动作。

真正的动作仍然通过审批引擎发生。

这可能比“在右侧塞一个 AI 小框”更接近下一代审批体验。

九、这件事的落脚点:企业要把审批当成正式产品来做

审批不是后台杂活,它是企业最适合被 AI 改造的责任现场。

每个企业都值得把审批当作一个正式事项来对待。

不是因为审批最性感。

而是因为审批天然包含数据、规则、权限、责任和协同。

这五件事,正好是企业 AI 落地绕不开的基本功。

如果一个企业连审批都做不好,就很难做好更复杂的流程智能体。

我建议从三步开始。

第一,选一个高频但风险可控的审批类型。

不要一上来碰所有流程。

先找材料重复、规则相对稳定、审批人痛苦明显的场景。

第二,把历史审批意见和退回原因整理出来。

不要急着训练模型。

先看企业过去到底怎么判断,哪些规则是明规则,哪些规则只是经验。

第三,先做后台并行校验。

AI 先不直接改流程,只在后台和人工判断对比。

当它能稳定解释“为什么同意、为什么退回、为什么要补材料”时,再逐步开放低风险动作。

这条路不炫。

但它更像企业真正能走通的路。

AI 不是拿来替人背锅的。

AI 是帮助组织把经验变成规则,把规则变成能力,把能力放回流程里。

如果你也在做审批流、流程管理、OA/BPM 或智能体审批,欢迎交流。

我最近也在设计新的审批产品形态。

这件事还有很多值得拆的地方。

资料参考:BPMN 标准来自 OMG/ISO 对业务流程建模与 notation 的说明;AI 风险治理参考 NIST AI RMF 1.0 对可信、可解释、可问责 AI 的框架要求。公开稿已隐去具体机构、产品名、演示名、价格细节和内部识别信息。

OMG BPMN 2.0.2 · ISO/IEC 19510:2013 · NIST AI RMF 1.0