SAP 把智能体接进流程：73% 卡试点，12.6% 报出 ROI

一份 AI 采购合同签下去两年，CFO 会问同一个问题：这笔钱买到了什么。Futurum 在 9 月的 CIO 调研里给出了买方答案的分布——73.3% 从外部采购 AI 的组织停在「上了系统但拿不到 ROI」，或者 ROI 只出现在试点里；能报出规模化、可持续回报的只有 12.6%。

同一个月的另一边，SAP 把智能体的所有者、风险分级和上线后的偏离监测搬进了它的流程与架构产品线。把这两件事放在一起，有一条可操作的读法：卡住规模化的不是模型能力，而是证据链少了产出方。那个能进预算流程的 ROI 数字，目前在大多数组织里没有人负责在生产中把它记下来。

一、73.3% 与 12.6% 之间，缺的是可审计的输入项

Futurum Group 在 2026 年 9 月 24 日发表的分析基于 SAP 9 月 22 日在亚特兰大 Transformation Excellence Summit 上的发布，引用了两份自研调研。第一份是 2026 年 9 月的 CIO 调研：从外部采购 AI 的组织里，73.3% 处在「部署了但没拿到 ROI」或「ROI 只到试点」的阶段，报出规模化可持续回报的只有 12.6%。第二份是 2H 2026 企业软件决策者调研（n=833，2026 年 8 月）：近期软件采购的预期回报与实际回报都落在约 14% 附近，而 41.5% 的决策者明确表示，有一份经过验证的 ROI 研究会提高他们批预算的信心。

这三组数字要连起来读。41.5% 描述的是买方的决策机制：预算批不批，取决于能不能拿到一份可以被复核的回报证据。73.3% 与 12.6% 描述的是这个机制当前的供给：绝大多数组织拿不出这份证据。中间那个 14% 是另一层信息——买方对软件回报的预期本身已经不高，落空却仍然普遍，说明问题不在期望管理，而在交付之后没人记账。

口径必须交代清楚。两组数字都出自 Futurum 自研调研，该机构同时对外销售定制研究，同一页面就是它的服务招揽页；样本框没有公开，谁被问、覆盖哪些行业、是否包含它的客户，外界无从核对。因此这是一份利益相关方调研，不是中立普查。那个 14% 是区间中点估计，不是精确均值，也不能当作「AI 回报就是 14%」来引用。

二、为什么「上了没规模化」不是模型问题

把一个 AI 项目的钱拆开看，会看到三笔账，其中只有两笔有单据。第一笔是采购：预算批出、合同签订、发票入账，全程有记录。第二笔是部署：许可证、算力、集成工时，也都有记录。第三笔是价值：某个岗位少做一步，某个案件少返工一次，某张工单提前两天闭合。第三笔账发生在业务流程里，而业务流程通常不会为「省下的那一步」开发票。

于是 ROI 在多数组织里不是一条记录，而是一次事后研究：抽样、访谈、估算工时节省，最后写成一页结论。事后研究有两个结构性弱点。它给出的是区间而不是可核验的量，进不了按数字审批的预算流程；它的成本落在那个人均产能已经吃紧的团队身上——最该去产出证据的人，恰恰最没有时间产出它。

这就是 73.3% 的机制解释：不是模型做不到，而是做到之后没有留下可审计的痕迹。第二年的预算自然倾向于不追加，因为决策者手上没有比去年更硬的东西。

这个解释有边界。它覆盖的是「用得出但报不出」的项目；对那些确实没有产生价值的项目，缺证据不是原因，缺价值才是。想知道自己落在哪一边，有一个简单测试：把过去一个季度里所有声称有效的 AI 动作列出来，逐个问「这件事如果我们不做，哪个数字会变差，变差多少」。答不出来的条目属于证据问题；答得出来但数字没变的，属于价值问题。

顺带指出三种在预算桌上最常被当成证据、却过不了复核的材料。第一种是供应商给的案例数字，它们的缺陷通常不是虚假，而是缺分母——没有说明样本怎么选、基线是什么、统计周期多长。一个「效率提升 40%」如果分母是选定的一个团队、一个季度，它就无法和另一个部门的数字对话。第二种是内部满意度调查，它测的是感受，而感受在预算流程里没有兑换率，把「用户觉得好用」写进汇报等于把决策成本转给下一个审批人。第三种是一次性的对照试验，方法上比前两种严谨，结论却绑定在一组条件上：特定数据、特定提示词、特定团队；条件一变结论不可复现，第二年自然不敢续投。

供应商一侧还有一层结构性原因。他们能观测到的是用量，比如调用次数、token 消耗、活跃席位；观测不到的是业务闭合，比如案件是否提前关闭、返工是否真的减少。用量数据天然可得，闭合数据只有买方自己的系统里才有。这解释了一个常见错位：买方要回报，卖方给使用率，双方都以为对方在敷衍。

三种材料的共同点是缺少一条可重复的读取路径。审计要的不是「曾经达到过」，而是「现在随时可以再取一次」。这两个要求的差别，决定了证据是资产还是一次性消耗品。

三、SAP 把证据链搬进了哪里

SAP 这一轮动作的产品面可以直接点名：AI Agent Hub 把智能体、大模型和 MCP server 映射到能力与所有者；Cloud ALM 在生产中追踪智能体的动作并识别偏离；Signavio 提供流程挖掘与 AI 辅助的流程设计；LeanIX 把架构原则库与 AI 企业架构助手放进设计阶段；WalkMe 负责员工采纳与访问；Company Memory 仍处于 preview 阶段。

单看每一条都是功能清单，合起来看是一个结构变化：这些是系统记录里的部件。企业原本把「谁负责这个智能体」「它上线后偏离了多少」写在文档、台账或咨询报告里，现在这两个问题的答案被要求写进 ERP 与流程套件本身。一旦写进系统记录，它们就变成可导出、可按时间切片、可放进审计包的数据，而不是每次都要重新调研才能回答的问题。

换句话说，ROI 证据的产出方正在从外部研究转向系统记录。这笔转移对买方的影响是可测的：当供应商的套件本身能输出智能体的动作与偏离记录，买方在验收时可以要求导出数据，而不是接受一份结论。

边界要同时说清。SAP 的治理助手里包含 EU AI Act 与 NIST 的合规智能，那属于合规车道，本文不评估；产品名与能力描述来自厂商发布，我们未做功能验证，也不主张这些部件能替代企业自己的验收责任。本文读的只是「哪些数据面被接进了系统记录」这一点，它已经足够支撑上面的结构判断。

四、同一方向的第二组数字：每一美元买到什么

另一个口径可以佐证同一件事，但不能和上面的数字合并。Entelligence Research 在 2026 年 5 月分析了 2,444 家组织、超过 100 万个 pull request，结论是：每 1 美元投在 AI 编码工具上，只有 18 美分变成上线的产品，其余 82 美分花在修复、返工与审阅 AI 生成的代码上。这组数据来自 ORF 9 月 19 日的分析文章，抽样与口径定义未公开，作者本身是编码工具赛道的研究方。

不能合并的原因很直接：73.3% 与 12.6% 的分母是组织，18 与 82 的分母是美元，两者回答的是不同问题——前者问有没有规模化价值，后者问每一块钱买到多少。并列摆出可以互为旁证，合成一个「AI 效率」数字就是错的。

在 18 与 82 里，我们读到的是记账单位的问题：一个组织如果只按投入记账、不把「上线」这个闭合动作记下来，它就永远分不清哪 18 美分是有效的。这也是我们自己在智能体运营里采用的口径——按成功闭合的任务记成本，而不是按 token 记。理由和这里一样：token 是投入，闭合的任务才是产出。我们此前专门拆过这个口径的计算方式，见文末相关分析。

五、我们的判断

第一，ROI 证据应当由运行时产出，而不是由研究产出。研究回答的是「这类项目一般怎样」，适合立项阶段；运行时的记录回答的是「这个季度这笔钱买到了什么」，适合续投。把后一个问题交给前者，等于每一轮预算评审都重新做一次调研，成本高，结论软。

第二，采购条款该改的是要求，不是价格。不要问供应商「你们的 ROI 是多少」，而是要求在试点结束前导出过去 30 天的任务级记录：任务是什么、花了多少、结果是什么、谁验证的。这四个字段缺一个，这条记录就进不了审计包。41.5% 那个数字可以直接用在这里——买方要一份经过验证的 ROI 研究，那就把「可验证」写进合同，而不是写进期望。

第三，谁掌握系统记录，谁定义验收单位。SAP 的动作是这个判断在卖方侧的一个样本；对买方同样成立：如果你把验收单位交给供应商定义，等于把记账权交出去。这个单位可以是任务、工单、案件或报价，但必须由业务方定义，而且必须在项目开始前定义。

第四，产品存在不产生证据。本文不主张买一套治理产品或流程套件就能拿到 ROI——证据只在运行时把动作记下来之后才存在。工具能降低记录的成本，不能替代记录本身。对正在写下一轮预算的组织，我们建议先补记录，再谈平台。

把「任务级记录」落到可以开工的程度，需要四个字段：任务标识与业务对象（哪张工单、哪个案件、哪次报价）；闭合时间与状态（它究竟结束了没有）；这条任务的变动成本（算力、模型调用、人工复核的工时）；以及验证方（谁确认这个结果可以接受）。四个字段里，验证方最常被漏掉，也最能区分真假证据：没有验证方，一条记录只能证明系统跑过，不能证明事情办成。很多智能体项目在验收时发现自己回答不了成功率，根源就在这里——失败的定义从一开始就没人写下来。

六、边界与不确定性

• Futurum 的两份调研均为该机构自研，方法未公开，同页为其定制研究招揽页，属利益相关方调研。
• SAP 的产品能力是厂商发布口径，本文未做第三方验证。
• 73.3% 与 12.6% 的分母是「从外部采购 AI 的组织」，不等同于全部企业。
• 18 与 82 美分是 2026 年 5 月的第三方分析结论，抽样与口径未公开，不是全行业普查。
• 本文不评估 SAP 治理助手中的合规智能，那属于合规车道的议题。

七、预算评审前可以做的三件事

一，给每个在跑的 AI 项目补一个「闭合单位」的定义：一个案件、一次报价、一张工单。没有闭合单位，后面所有数字都只能写成区间。

二，把「可导出」写进验收条件。要求供应商在试点结束前导出 30 天的任务级记录；导不出来，就按试点未通过处理。这条比 ROI 承诺更容易验证，也更容易在合同里写清楚。

三，用一个季度的数据看分布，而不是看百分比。同一闭合单位的成本，均值与标准差比一个 ROI 百分比更早暴露问题：均值不动而标准差收窄，说明流程正在变得可预测，这本身就是可以写进下一次预算的材料。

这三件事做完，你手上会有一条能进预算流程的记录。剩下的问题就不再是「AI 值不值」，而是「下个季度把这条记录的斜率往哪个方向推」。

如果只能做一件事，就做第一条。闭合单位是整个链条里成本最低、杠杆最大的一项：它不需要工具、不需要预算、不需要供应商配合，只需要业务方在项目开始前把「什么算完成」写下来。写下来之后，前面那些数字才有地方落，供应商的承诺也才有地方核。

参考来源：Futurum Group《SAP Links AI Agents to Business Processes and Oversight》（2026-09-24，含其两份自研调研口径）futurumgroup.com/insights/sap-links-ai-agents-to-business-processes-and-oversight/ ；ORF《From Tokens to Weights: The Changing Value of AI》（2026-09-19，引述 Entelligence Research 2026 年 5 月分析）www.orfonline.org/expert-speak/from-tokens-to-weights-the-changing-value-of-ai