SAP因AI成本收缩背后：ERP AI化成本重构与应对策略

从去年开始企业软件圈子里一直有一个隐约的焦虑AI 到底是来帮 ERP 降本的还是来让 ERP 厂商多花钱的最近的一条新闻把这个焦虑摆到了台面上。据公开新闻报道软件巨头 SAP 因为 AI 带来的高昂成本开始暂停大部分商务差旅并放缓招聘节奏。很多人的第一反应是SAP 不是一直在推 AI 吗怎么反而被 AI 拖累了这篇文章不谈八卦只谈技术判断和落地影响。我想先给出一个明确结论SAP 这次收缩不是 AI 战略失败而是企业软件的成本结构正在被 AI 重写。过去卖软件许可证、收维护费的商业模式正在面对“每次调用都要付钱”的大模型算力账单。SAP 暂停差旅和招聘本质上是把省下来的钱继续砸进 AI 基础设施。这篇文章会从四个层面展开AI 成本到底贵在哪里、SAP 的 AI 布局为什么停不下来、对企业 IT 负责人和 SAP 顾问有什么实际影响以及企业预算 SAP AI 项目时应该怎么算账、怎么避坑。如果你是正在做 S/4HANA、BTP、FICO/MM/SD 相关项目的技术人这篇文章值得读完再收藏。1. SAP 这次“勒紧腰带”到底发生了什么先说新闻本身。从公开报道看SAP 正在限制大部分商务差旅同时大部分岗位的招聘也进入了冻结状态。表面上是两个 HR 和财务动作但放在一起看信号完全不同。差旅暂停是短期现金流管理招聘收缩则是中期组织策略。但 SAP 并不是没有钱——过去几年 SAP 在云转型上投入巨大S/4HANA Cloud、RISE with SAP 的订阅收入已经逐渐成为主力。那为什么还要因为 AI 成本做收缩这里真正值得关注的是 AI 的计费模式和传统软件完全不同。传统 ERP 时代SAP 的成本结构以研发人力、销售和实施服务为主。交付一套 S/4HANA客户买的是许可证和每年的维护费边际成本是固定的。但生成式 AI 不一样模型训练要烧 GPU每次用户跟 Joule 对话、每次调用大模型 API都是真金白银的 token 成本。一句话ERP 厂商第一次遇到了“用的人越多成本越高”的窘境。SAP 暂停差旅和招聘本质上是把旧业务里能省的钱全部腾挪给 AI 这个“吞金兽”。对于正在用 SAP 的企业来说这个消息不应该只当新闻看它是整个企业软件定价模式转型的信号。过去你买 SAP 是按模块、按用户数未来很可能是按算力、按 token、按 AI 调用量来付费。IT 预算的规划方式必须跟着变。2. AI 的“高昂成本”到底花在哪了很多人会问大模型 API 不是很便宜吗一次调用才几分钱。这确实是很多人的直觉误区。AI 成本高不是高在单次调用而是高在下面三笔账。2.1 训练和推理的算力账单一个前沿大模型的训练成本以亿美元计这已经不需要再重复。但企业软件真正头疼的是推理成本——模型训练完之后每次生成回答都需要 GPU 计算。SAP 做的是企业级应用和 C 端聊天机器人不一样。Joule 每次回答不是简单“生成一段文字”而是要结合 SAP 系统里的业务上下文可能需要检索主数据、读取物料凭证、汇总多个订单状态然后再生成分析结论。这意味着每一次交互背后都是更大的上下文窗口和更高的计算消耗。更关键的是企业软件的 AI 不能出现幻觉。财务月结的 AI 助手如果给错了成本中心数据不是一句“抱歉”就能解决的。为了保证准确率SAP 需要在提示词工程、RAG检索增强生成、模型微调上做大量工作这些都是持续投入。2.2 企业级私有化和合规成本消费级 AI 可以直接调用云端大模型但 SAP 客户的数据大多涉及企业核心经营数据很多公司要求私有化部署或至少是专属区域部署。这意味着 SAP 不能只在 OpenAI 或 Azure 上挂一个公共 API 就完事需要搭建自己的 AI Foundation提供模型托管、向量数据库、数据脱敏、审计日志等企业级能力。这些基础设施的运维成本都被算进了 AI 的“隐形成本”。所以当我们看到 SAP 暂停招聘时不应理解为 SAP 不招 AI 工程师了而是 SAP 会把更多人力预算投向 AI 基础设施削减的是传统业务和行政岗位。2.3 生态系统的连锁成本SAP 的 AI 不是只服务内部还要开放给合作伙伴和客户。当你在 BTP 上构建一个 AI Agent用来处理采购申请异常这个 Agent 的每一次运行都会消耗 SAP 的资源。从架构设计、模型调优到故障排查整个生态都需要重新学习。可以把这个过程类比成当年从本地部署迁移到云迁移本身不产生直接收入但你不得不做否则未来架构会被淘汰。SAP 现在的 AI 投入就处在这样一个“不得不做”的阶段。成本类型传统 SAP 项目SAP AI 项目基础软件许可证永久买断订阅 按用量计费运行资源服务器固定成本GPU 算力弹性成本调优成本业务顾问配置提示词 RAG 微调错误成本事务回滚可修正生成式错误更难追溯治理成本权限/审计较成熟模型可解释性待完善这张表的价值在于如果企业还在用“传统 ERP 上线的成本框架”去估算 AI 项目一定会严重低估预算。3. SAP 的 AI 布局为什么停不下来从战略上看SAP 几乎没有退路。三年前 SAP 发布的 Joule 生成式 AI 助手已经逐步嵌入 S/4HANA、SuccessFactors、Ariba 等产品线。更早的 Business AI 理念也在把 AI 能力集成到财务管理、供应链、人力资源等业务场景中。这些布局的共同点是AI 不再是 SAP 的一个独立产品而是整个产品矩阵的底座。如果 SAP 现在因为成本停止 AI 投入未来所有产品的竞争力都会被削弱。这不是想不想停的问题是根本停不下来。但问题在于AI 投入的回本周期比传统软件长得多。传统软件卖一个模块实施完就能确认收入AI 功能则要持续优化因为模型会过时、效果会衰减企业客户的期望值还在不断提高。这就解释了 SAP 为什么会选择“暂停差旅和招聘”这种看似保守的降本方式——既不伤 AI 主线又能够向资本市场传递“我们在控制成本”的信号。可以把这理解为一次主动的成本重构省下非核心开支集中资源打 AI 这场硬仗。对客户而言这里有一个更实际的判断SAP 的 AI 功能会越来越贵但也会越来越深地嵌入核心业务流程。你现在不开始建设 AI 能力未来三到五年同样的系统维护成本可能会更高。4. ERP AI 的成本账技术负责人应该怎么算既然 AI 成本这么高企业是不是就不要做 SAP AI 项目了恰恰相反应该做但要换一种算法来评估。传统的 SAP 项目评估方式是算许可证费用、实施人天、硬件配置。AI 项目则要增加一个新维度运行成本。我在过去的文章中一直强调一个观点AI 项目的第一份预算不应该是“建设预算”而应该是“年度运行预算”。具体来说一个 SAP AI 场景的成本模型至少包含六项成本项目说明评估重点模型调用费每次生成/分析的 token 费用调用频率、上下文长度算力资源GPU/CPU 资源私有化还是公有云数据准备清洗、向量化、更新数据质量决定效果人天成本提示词调优、Agent 开发往往被低估评估与治理输出准确性抽查、审计关键行业必选项回滚储备出错后的补偿机制财务类场景尤其重要这里有一个非常典型的误区很多人只算模型调用费觉得一个月几千块很便宜。但真正的成本大头是按人天计的开发和治理费用以及 AI 出错后带来的业务风险成本。举一个财务场景的例子如果 AI 助手在月结时给成本中心分配建议偶尔出错一次导致账务调整其代价可能超过一整年的 API 费用。所以在做 AI 成本评估时业务损失预期必须进入模型。下面给一个最小可用的 Python 成本估算示例适合在项目立项阶段做初步测算。# 文件路径cost_estimator.py # 用途估算 SAP 业务场景的 AI 调用成本示意代码 def estimate_monthly_cost( users: int, calls_per_user_per_day: int, avg_input_tokens: int, avg_output_tokens: int, price_per_million_input: float, price_per_million_output: float, workdays: int 22 ) - dict: 估算一个 SAP AI 场景的月度调用费用。 参数中的价格为示意请以实际供应商报价为准。 total_calls users * calls_per_user_per_day * workdays input_tokens total_calls * avg_input_tokens output_tokens total_calls * avg_output_tokens input_cost input_tokens / 1_000_000 * price_per_million_input output_cost output_tokens / 1_000_000 * price_per_million_output total_cost input_cost output_cost return { total_calls: total_calls, input_tokens: input_tokens, output_tokens: output_tokens, input_cost: round(input_cost, 2), output_cost: round(output_cost, 2), total_cost: round(total_cost, 2), } # 示例50 个用户每人每天调用 10 次 # 输入 2000 token输出 500 token result estimate_monthly_cost( users50, calls_per_user_per_day10, avg_input_tokens2000, avg_output_tokens500, price_per_million_input15, price_per_million_output60, ) print(result)运行之后会得到这样的结果总调用次数 11000 次输入 2200 万 token输出 550 万 token总费用大概 660 元人民币左右。单看这个数字确实不高。但请注意这只是“调用费”。如果加上私有化部署的 GPU 资源、每周一次的模型效果评估、主数据清洗和向量化更新月度成本会再翻几倍。如果 AI 嵌入的是财务月结这种核心场景还需要安排 QA 人员抽查输出人天成本更高。所以我的建议是所有 SAP AI 项目立项时必须同时提交“建设预算”和“三年运行预算”。只报建设预算、不提运行成本的项目大概率会在上线后因为费用超支被叫停。5. SAP 顾问和 IT 团队会受到什么影响聊完成本再来说人。SAP 暂停差旅和招聘对顾问圈的冲击是最直接的。第一个变化是交付模式。过去做 SAP 项目顾问动不动就要飞到客户现场一待就是几周。现在差旅被砍掉远程交付、离岸交付会成为常态。虽然此前 S/4HANA 项目已经有大量远程工作但这次政策会进一步固化下来。对顾问来说这意味着“以出差补贴为隐性收入”的时代彻底结束了而远程交付的质量更难体现。以前客户信任你是因为你在会议室里和业务部门吵过架现在要建立信任只能靠文档质量、交付节点和问题响应速度。第二个变化是技能结构。纯 ABAP、纯 FICO 配置的顾问如果只会传统实施收入空间会逐渐被压缩。但懂得 API 集成、会写 Python 脚本处理数据、能理解大模型提示词原理、能把 SAP 数据通过 OData 或 Webservice 喂给 AI 模型的顾问价值会快速上升。这不是什么未来判断而是已经在发生的事。从很多 SAP 社区和招聘平台的趋势看企业找的已经不是“SAP 顾问”而是“懂 SAP 的 AI 应用工程师”。第三个变化是服务内容。传统 SAP 实施的核心是蓝图、配置、测试、上线。未来则是数据准备、AI 场景规划、提示词调优、模型效果评估、异常处理。系统上线不再是终点AI 效果的持续优化才是。6. AI 在 SAP 业务场景里到底能做哪些事你可能已经感觉到了上面的讨论都还比较宏观。接下来我们落到具体业务场景。我从一线 SAP 使用者经常遇到的热搜问题里挑几个典型的场景来分析。6.1 MRP 生成的采购申请行号问题很多 MM 顾问都会遇到一个经典问题MRP 跑完之后生成的采购申请没有行号。传统排查方式需要看 MRP 参数、物料主数据、工厂级配置一步步翻菜单。这个过程非常吃经验。AI 能做的是把这种“经验排查”变成“对话式排查”。你可以让 AI 助手读取 MRP 运行日志、采购申请表结构再结合你的配置项给出可能的原因列表和逐步排查建议。但这里有一个前提AI 必须先能访问到业务数据。如果企业还没有建好数据接口AI 再强也没用。6.2 SD 信用决策SD 模块里信用决策是一个典型的高风险场景。过去销售订单的信用检查完全依赖预设规则客户信用额度超了系统直接拦截。AI 可以在这个基础上做得更细结合客户的账龄、历史回款、当前市场环境给出风险评分和放行建议。但请注意AI 在信用场景里只能做“建议者”不能做“决策者”。信贷范围的调整、信用额度的审批仍然需要财务负责人确认。这里最忌讳的是让 AI 自动绕过信用管控——一旦企业出现坏账责任归属会很麻烦。6.3 工单结算与获利能力分析CO 模块的工单结算是财务月结里最繁琐的工作之一。差异分摊、WIP 计算、结算参数的调整每一步都可能出错。AI 的价值在于异常检测跑完结算之后让 AI 自动扫一遍差异率异常的成本中心或工单标记出偏差超过阈值的数据再由财务人员去确认。这比让 AI 直接做“结算操作”要稳妥得多。生成式 AI 适合做模式识别和解释不适合做需要严格事务一致性的系统写入。6.4 质量检验计划Inspection Plan再举一个生产制造场景质量工程师创建检验计划往往需要参考标准和历史批次。AI 可以先用自然语言生成检验计划草稿从 BOM、工艺路线和既有计划中提取字段再由质量工程师修改确认。这个场景的落地难度相对低因为错误可以由人来兜底不会直接影响财务数据。从这些场景能得出一个清晰判断AI 在 SAP 里最合适的角色是“高频操作的辅助者”和“异常模式的发现者”而不是“核心事务的自动执行者”。任何涉及财务、信用、物料过账的环节AI 输出都只能作为参考人工审批必须保留。7. 一个最小可参考的 SAP AI 集成示例前面说了这么多接下来给一个最小可参考的集成思路。需要提前说明这里不是 SAP 官方标准代码而是一个通用集成思路实际项目中建议通过 SAP AI Core 或 BTP 的 AI 服务来封装模型能力。核心思路是把 SAP 里的主数据提取为结构化文本调用大模型 API 做分类或摘要生成再把结果回传或保存为 CSV 供用户核对。7.1 从 SAP 提取物料主数据并调用大模型假设场景是批量给物料描述打上品类标签方便后续采购分析。# 示意代码从 SAP 提取数据后调用模型 API # 实际项目中建议通过 BTP Destination 管理接口凭证 curl -X POST https://your-llm-endpoint.example.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { model: your-model-name, messages: [ { role: system, content: 你是物料分类助手根据物料描述输出标准品类代码和简短理由。 }, { role: user, content: 物料描述不锈钢法兰盘 DN80 304材质 } ], temperature: 0.2 }返回结果大致是{ choices: [ { message: { content: 品类代码PIPE-FLANGE-304\n理由304材质不锈钢法兰盘适用管道连接场景。 } } ] }7.2 Python 批量处理 CSV实际项目中数据通常不在 API 测试环境而是在 SAP 导出的 Excel 或 CSV 里。下面给一个批量处理脚本# 文件路径batch_ai_classify.py # 用途读取 SAP 导出的物料 CSV调用大模型 API 生成品类标签示意代码 import csv import json import time from typing import Dict import requests API_URL https://your-llm-endpoint.example.com/v1/chat/completions API_KEY YOUR_API_KEY # 生产环境务必通过密钥管理不要硬编码 def classify_material(description: str) - str: payload { model: your-model-name, messages: [ {role: system, content: 你是物料分类助手输出品类代码。}, {role: user, content: f物料描述{description}} ], temperature: 0.2, } headers { Content-Type: application/json, Authorization: fBearer {API_KEY}, } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() content resp.json()[choices][0][message][content] # 实际这里需要解析 content 中的品类代码建议用结构化输出 return content.strip() def process_csv(input_path: str, output_path: str) - None: with open(input_path, moder, encodingutf-8-sig) as fin, \ open(output_path, modew, encodingutf-8-sig, newline) as fout: reader csv.DictReader(fin) fieldnames reader.fieldnames [ai_category] writer csv.DictWriter(fout, fieldnamesfieldnames) writer.writeheader() for row in reader: description row.get(物料描述, ) if not description: continue try: row[ai_category] classify_material(description) except Exception as exc: row[ai_category] fERROR: {exc} writer.writerow(row) # 注意控制请求频率避免触发限流 time.sleep(0.5) if __name__ __main__: process_csv(sap_material_export.csv, sap_material_classified.csv)这段代码的关键点有三个第一temperature设置为 0.2降低生成随机性尽量让 AI 输出稳定。第二每次 API 调用后 sleep 0.5 秒防止频率过高被限流。第三任何异常都写入 CSV 的ai_category列而不是中断整个批处理——因为物料数据量通常很大一条失败不应该导致全部重跑。但必须强调这种“批量导出再回传”的方式适合做离线分析不适合做实时系统集成。生产环境应该通过 SAP BTP、OData 服务或中间件实现数据的安全流转和权限控制而不是把整个物料主数据表放进一个 Python 脚本里跑。8. 企业在预算 SAP AI 项目时应该避开哪些坑AI 项目失败很多时候不是技术问题而是从一开始的方向和预期就错了。结合 SAP 项目的实施经验下面几个坑最常见。坑具体表现后果正确做法把 AI 当咨询替代品以为买了 AI 就能省下业务顾问业务流程没梳理AI 输出质量差先做蓝图再上 AI忽略主数据质量物料、科目、客户主数据常年不维护AI 学习了脏数据越用越错先做数据治理专项拿生产环境直接测试直接在正式系统调 AI 接口数据风险高出问题难回滚用测试或沙箱环境验证没有异常兜底机制AI 输出错误时无人复核业务数据混乱责任不清设定人工审核流程只算 API 费用忽略算力和人天成本上线后发现预算超支按三年运行成本立项不清 token 计量方式上下文越长费用翻倍财务对账困难项目和财务提前对齐追求全面自动非要在财务场景做全自动处理一旦出错影响月结先做决策支持再谈自动化这七条里面主数据质量是 SAP AI 项目最容易被低估的一环。很多企业 SAP 系统用了多年供应商主数据存在重复、停用、字段缺失的情况。这些问题在传统人工业务场景里可能只是效率问题但在 AI 场景中会被无限放大。举个例子如果你用 AI 做供应商风险分析但供应商主数据的“国家”字段 30% 是空的模型推断出来的结论就不可信。所以企业如果打算上 SAP AI 项目第一件事不是选模型而是安排数据清洗。另外还有一条务实的提醒所有 AI 输出都要保留审计轨迹。建议在系统里记录模型版本、输入摘要、输出内容和审核人。未来一旦出现业务争议可以快速定位是模型判断问题还是数据问题。这个操作看起来多花一点开发量但能省下大量的扯皮时间。9. 对从业者和企业的下一步建议文章写到这里该收尾了。这里不想做什么宏大总结只给三条可以直接用的建议。第一条建议是给 SAP 顾问的重新评估你的技能组合。如果今天你还是只会反复看 SM30 配置项、记事务代码不去了解 API、数据模型、AI 提示词和 Token 计费未来几年的议价能力只会越来越弱。但如果你能同时回答“这个配置在哪个表”和“这个场景怎样接 AI 成本更低”你就是项目里不可替代的人。第二条建议是给企业 IT 负责人的先选一个小场景跑通再扩。不要一上来就规划一个“SAP 全业务 AI Copilot”那是一个无底洞。挑一个影响面小、数据质量高、业务价值清晰的场景比如物料描述的自动分类、SD 订单的异常检测、MRP 采购申请的问题排查。跑通之后用真实的数据验证 ROI再决定是否扩大到财务月结或供应链计划这类核心场景。第三条建议是给自己做年度规划的建立 AI 成本基线。无论你用什么平台、什么模型从第一个试点项目开始就记录每次调用的 token 量、模型版本、业务结果和数据质量评分。三个月后回看你会发现这些数据比任何外部白皮书都有价值。因为只有你自己的历史数据才能帮你回答“AI 到底值不值”这个问题。SAP 暂停的是差旅和招聘它并没有暂停 AI 投入。这更像是在高成本和强竞争之间用组织动作换战略空间。对于每一个身在 SAP 生态里的从业者来说真正被重新定价的其实是我们自己的技能组合。AI 会不会替代 SAP 顾问答案取决于你把它当成对手还是当成工具。