这条关于 SAP 的新闻，在 ERP 和 AI 两个圈子都引起了讨论：SAP 宣布暂停大部分差旅和招聘，理由是 AI 成本飙升。在很多人印象里，SAP 是一家做 ERP 的老牌软件巨头，和 AI 的关联并不算紧密。但过去两年，SAP 恰恰是传统企业软件里押注 AI 最激进的公司之一。这次暂停差旅和招聘，并不是简单的“省一点差旅费”，而更像一次预算压力测试：当生成式 AI 的成本从“实验费用”变成“企业级固定支出”时，即使是营收规模庞大的软件巨头，也要重新算账。
这篇文章想聊的不是新闻本身，而是新闻背后三个技术问题：AI 成本在 SAP 这样的企业软件公司里到底花在哪；SAP 的 AI 战略为什么天然比通用 AI 更贵；以及我们这些做 SAP 开发、运维、顾问的人，应该怎么面对这波变化。
1. 一个新闻切片：AI 成本怎么成了 SAP 的预算难题
大家都在用 AI，为什么偏偏 SAP 会因为 AI 成本“收缩”？这需要先把标题拆开看。
SAP 暂停的是“大部分差旅和招聘”，不是停止产品研发，也不是停止客户交付。这意味着核心业务仍在运转，被收紧的是可变的、非核心的支出。差旅和招聘，恰好是大型软件公司里两个弹性比较大的预算池。而标题里点明的原因——“AI 的飙升成本”（AI's Soaring Cost），说明 AI 投入已经从“锦上添花”变成了“预算硬约束”。
过去两年，SAP 在 AI 方向上动作不小：发布生成式 AI 助手 Joule，把它嵌入 S/4HANA、SuccessFactors、Ariba 等产品线；在 SAP Business Technology Platform 上提供 AI 服务；同时推动大量行业云解决方案里的 AI 功能。这些投入不是一次性的，而是持续性的。模型调用、算力资源、数据工程、合规审计、平台集成，每一项都对应着持续现金流。
更关键的是，企业级软件的 AI 成本和消费级 AI 完全不同。消费级 AI 可以共用一套模型服务，边际成本相对可控。但 SAP 的客户是大型企业，每个客户的数据结构、业务流程、权限模型、合规要求都不一样。这意味着 SAP 不能简单地“训练一个大模型卖给所有客户”，而是要在每个客户的业务上下文里做数据接入、权限映射、提示词定制、结果验证。这种定制化程度直接拉高了单位成本。
对 SAP 生态里的开发者来说，这个新闻释放的信号很明确：AI 不再是停留在 PPT 上的概念，而是进入了公司的财务预算表。任何一项 AI 功能，如果不能证明它对业务有实际价值，或者成本结构不可控，就会在预算审查中被淘汰。这不是悲观，而是技术投入走向成熟的表现。
2. 生成式 AI 在企业级软件里的成本到底花在哪
要理解 SAP 为什么要为 AI 控制成本，先得拆解企业级软件的 AI 成本结构。和传统软件“开发一次、复制部署”的成本模型不同，生成式 AI 的成本是持续性的，而且是多层叠加的。
| 成本层级 | 主要内容 | 传统软件 | 生成式 AI |
|---|---|---|---|
| 算力层 | GPU/CPU 资源、模型训练与推理 | 一次性采购为主 | 持续推理支出，随调用量增长 |
| 模型层 | 基座模型调用费用、微调费用 | 无 | 按 token 计费或按实例计费 |
| 数据层 | 数据清洗、标注、向量化、知识库构建 | 一次性投入 | 持续更新与维护 |
| 集成层 | 与 ERP、CRM、流程引擎对接 | 一次性开发 | 每个客户/场景单独适配 |
| 合规层 | 数据隐私、审计日志、权限控制 | 一次性建设 | 每次调用都要验证 |
| 应用层 | 前端界面、交互逻辑 | 一次性开发 | 需要随着模型升级持续调整 |
这张表说明了一个核心问题：传统软件的成本大头在“建设期”，上线之后边际成本很低；而生成式 AI 的成本大头在“运行期”，业务用得越多，成本越高。
具体到 SAP 的业务场景，这种成本特征更加明显。举几个实际例子：
物料需求计划中的 AI 辅助。SAP MM 模块里，MRP 运行后会生成采购申请，但如果某些采购申请没有行号，业务人员就需要手工检查原始单据、维护物料主数据。如果要用 AI 自动分析异常原因，需要把 MRP 的运行日志、物料主数据、采购历史、供应商信息全部向量化，并且每次运行都要调用模型推理。数据量一大，token 消耗非常可观。
信用决策场景。SAP SD 模块的信用管理涉及客户信用额度检查。传统做法是配置信贷范围、信用规则，系统按固定逻辑执行。如果引入 AI 做动态信用评估，比如结合市场行情、客户历史回款、订单利润率做综合判断，就需要模型实时推理，而且每一笔订单都可能触发一次调用。这类场景的调用频率极高，成本随业务量线性增长。
工单结算与获利能力分析。SAP CO 模块的工单结算、获利能力段分析，本身是复杂的配置和计算过程。AI 可以用来做异常归因、成本偏差预警，但前提是把大量财务凭证、成本中心、内部订单数据接入模型。这种企业级数据接入本身就比通用场景昂贵得多。
所以，SAP 的 AI 成本高，不是因为模型贵，而是因为“模型 + 企业数据 + 业务流程 + 合规控制”这套组合太贵。理解这一点，才能理解 SAP 为什么要收缩差旅和招聘。
3. SAP 的 AI 路线：从 Joule 到嵌入式场景
SAP 的 AI 战略不是做一个独立的聊天机器人，而是把 AI 嵌入到企业业务流程的每个操作节点里。这条路线决定了它的成本结构，也决定了它对开发者和顾问的技能要求。
按 SAP 官方公开信息，Joule 是 SAP 的生成式 AI 助手，定位是“理解 SAP 业务语义”的数字助理。它不是一个通用的 ChatGPT，而是深度绑定 SAP 产品体系的 AI 层。这意味着 Joule 要理解什么？要理解 SAP 的模块结构、事务代码、数据模型、业务文档、权限逻辑。随便举几个例子：
- SAP MD07：物料需求清单查询，用来分析物料供需情况；
- SM30：表维护工具，用于配置视图维护；
- CJ20N：项目系统模块的项目构造器，管理 WBS 元素和网络活动；
- WS_DELIVERY_UPDATE：交货单更新的 BAPI，常用于接口传输出厂交货信息；
- AFAMS：折旧表维护相关的事务代码。
这些事务代码和函数，业务顾问和开发人员需要长时间学习才能熟练使用。AI 的潜力在于降低这种操作门槛——业务用户可以直接用自然语言问“帮我查一下这个物料未来四周的供需缺口”“为什么这张采购申请没有行号”“昨天的交货单更新接口为什么报错”。但要让 AI 回答这些问题，SAP 需要把每个客户环境里的数据模型、权限规则、接口日志全部接入到模型上下文里。这恰恰是成本最高的部分。
从技术架构上看，SAP 的 AI 能力通常不是直接在 ERP 系统里跑一个大模型，而是通过 BTP 承载 AI 服务，再通过集成层把 AI 结果回写到业务系统。这种架构的好处是灵活、可以复用，坏处是多了一层平台费用和集成成本。具体到客户项目里，往往还要考虑：
- 数据是否允许出域；哪些字段可以发送给模型服务；
- 模型返回的结果是否需要人工复核，复核流程如何设计；
- AI 生成的建议是否有审计跟踪，能否追溯到原始数据；
- 不同国家和地区的合规要求不同，模型部署位置可能受限。
这些都不是“调用一个 API”那么简单。所以 SAP 的 AI 成本，本质上是一套企业级 AI 落地的综合成本。
4. AI 成本压力下的 SAP 生态：哪些业务反而更重要
AI 成本收缩，是不是意味着 SAP 的 AI 方向会停摆？从技术生态的角度看，恰恰相反。越是在成本压力下，企业越会关注 AI 的实际投资回报率，而不是追热点。这会带来一个结果：真正有价值的 SAP 核心业务、真正有深度的集成架构、真正能解决问题的顾问能力，反而会更受重视。
SAP 经典的业务模块，比如 MM、SD、FICO、PP、PM，依然是企业运行的基础。AI 只是在这些业务之上增加了智能化层，并没有改变核心业务逻辑。MRP 运行完之后，采购申请该审批还是审批；销售订单创建之后，信用检查该执行还是执行；工单结算该跑还是跑。AI 能做的，是让这些流程里的异常更容易被发现、让重复工作被自动处理、让决策建议更及时。
对 SAP 从业者来说，这意味着技能分层会更加明显。只会配置标准功能的顾问，竞争力会逐步下降；能在标准功能基础上，结合 AI 能力解决企业具体问题的顾问和开发，价值会上升。比如：
- 能理解 MRP 逻辑，同时能设计 AI 异常分析方案的 MM 顾问；
- 能配置信用管理，同时能设计 AI 信用评分模型的 SD 顾问；
- 能写 ABAP 和 Fiori 应用，同时能调用 AI 服务并处理返回结果的开发人员；
- 能做 BTP 集成，同时能估算 AI 调用成本、设计缓存策略的架构师。
这些岗位的共同特点是：既要懂 SAP 的“确定性逻辑”，又要理解 AI 的“概率性特征”。前者保证系统稳定，后者提供真正的增值。
5. 企业使用 SAP AI 功能时的成本控制思路
如果企业已经在使用 SAP 的 AI 功能，或者正在规划引入，成本控制是一个绕不开的话题。从技术实现角度看，有几种比较务实的思路。
5.1 按业务价值分层，不要“无差别 AI 化”
不是每个功能都需要大模型。比如采购申请的分类、发票的 OCR 识别、主数据清洗，这些任务相对标准，可以优先评估传统规则引擎或轻量模型。而像信用决策建议、需求预测、异常归因这类需要理解复杂业务上下文的场景，才适合调用大模型。
5.2 用缓存和复用降低模型调用量
同一个客户、同一类问题，在一定时间窗口里的答案往往是稳定的。可以在应用层做缓存，把 AI 返回的结果缓存起来，并用 SAP 的标准数据变更事件做缓存过期控制。这样可以显著减少模型调用次数，降低 token 成本。
5.3 控制上下文长度，优化提示词
很多企业级 AI 应用的成本失控，不是因为模型贵，而是因为每次调用都塞入了大量无关上下文。比如查询一个物料供需情况，不需要把整个物料主数据的所有字段都发给模型，只需要按需提取关键字段。控制上下文长度，是成本控制里最容易见效的一步。
下面给一个简单的 token 成本估算脚本，用来在项目前期快速评估 AI 调用成本。这个脚本是示意性的，具体参数需要以实际使用的模型服务为准。
# 文件路径：estimate_ai_cost.py # 作用：粗略估算 SAP 场景下 AI 调用的月度成本 def estimate_cost(daily_calls: int, avg_input_tokens: int, avg_output_tokens: int, input_price_per_1k: float, output_price_per_1k: float, workdays: int = 22) -> dict: """ daily_calls: 每天调用次数 avg_input_tokens: 每次调用的平均输入 token 数 avg_output_tokens: 每次调用的平均输出 token 数 input_price_per_1k: 每千输入 token 的价格，单位：元/千 token output_price_per_1k: 每千输出 token 的价格，单位：元/千 token workdays: 当月工作天数 """ monthly_calls = daily_calls * workdays input_cost = monthly_calls * avg_input_tokens / 1000 * input_price_per_1k output_cost = monthly_calls * avg_output_tokens / 1000 * output_price_per_1k total_cost = input_cost + output_cost return { "monthly_calls": monthly_calls, "input_cost": round(input_cost, 2), "output_cost": round(output_cost, 2), "total_cost": round(total_cost, 2) } # 示例：某 SAP 场景每天 500 次调用 # 每次输入 3000 token，输出 300 token result = estimate_cost( daily_calls=500, avg_input_tokens=3000, avg_output_tokens=300, input_price_per_1k=0.02, # 假定的输入价格，请按实际报价调整 output_price_per_1k=0.05 # 假定的输出价格，请按实际报价调整 ) print(result)这个脚本的价值不在于精确计算，而在于让技术和业务在项目早期就对“AI 是持续的运营成本”有共识。很多企业到了月底看到账单才发现超支，就是因为前期没有做类似的估算。
5.4 在 BTP 上配置 AI 服务时，明确权限与日志
如果使用 SAP BTP 的 AI 服务，建议在配置阶段就把权限、日志、用量监控这些基础工作做好。下面的配置片段是示意性的，重点在于展示这类平台配置通常包含的维度：模型端点、API Key、用量监控、日志级别。
# 文件路径：sap_btp_ai_service_config.yaml # 说明：这是配置思路示意，实际字段以 SAP BTP 官方文档为准 ai_service: provider: "hyperscaler-ai-provider" deployment: "au-1" # 部署区域，需结合数据合规要求选择 model: "enterprise-context-model" # 模型标识，按实际服务调整 auth: type: "OAuth2ClientCredentials" client_id: "${env:BTP_CLIENT_ID}" client_secret: "${env:BTP_CLIENT_SECRET}" observability: enable_usage_metrics: true log_level: "WARNING" # 生产环境建议使用 WARNING 级别 audit_log_enabled: true需要强调的是，生产环境的日志应该只记录必要的业务追踪信息，不要在日志里写入客户敏感数据、完整提示词或完整模型输出。这既是合规要求，也是控制日志存储成本的手段。
5.5 用传统 SAP 工具做监控和排错
AI 服务接入后，监控不能只靠 AI 平台自带的控制台。可以在 SAP 系统的日常运维工具里增加 AI 调用相关的检查项。比如使用 SAP SM30 维护 AI 配置相关的自定义表，使用事务代码或自定义报表查看接口调用记录。如果 AI 服务通过 RFC 或 OData 接口调用，那么 SAP 标准的接口日志事务代码（比如 WE02、WE05 或自定义日志表）同样适用于查错。
6. 对 SAP 开发者和顾问的 4 个实操建议
面对 SAP 因为 AI 成本而收缩差旅招聘这件事，技术人最该做的不是焦虑，而是重新梳理自己的技术栈。有几个方向性建议，个人觉得值得认真考虑。
6.1 把 AI 当成“业务流程内的一个动作”，不是独立工具
很多人的误区是把 AI 看作一个可以独立交付的产品，比如“做一个智能问答系统”。但在 SAP 场景里，AI 必须嵌入业务流程才有价值。比如“AI 自动分析 MRP 异常采购申请”“AI 辅助信用决策”“AI 解释工单结算差异”。设计思路上，要先有完整的业务流程，再考虑 AI 在哪个决策点介入。这个思路能显著降低集成成本，也让 AI 的价值更容易被业务部门看到。
6.2 学会估算 AI 成本，把成本作为技术选型的一等公民
架构师和技术负责人在做技术选型时，现在必须把 AI 调用成本纳入评估维度。是选择微调一个小模型，还是直接调用大模型 API？是每次实时推理，还是允许缓存结果？这些决策直接影响企业的运营成本。建议所有做 SAP 集成的技术人员都掌握最基本的 token 估算能力，至少能快速判断一个场景“大概贵不贵”。
6.3 先学好经典 SAP 技能，再跟进 AI 新特性
坦白讲，SAP 的 AI 功能迭代很快，但底层稳定的部分仍然是 ABAP、Fiori、模块配置、接口集成、系统运维。如果一个新人上来就只研究 SAP AI 而完全不懂 MM/SD/FICO 的业务逻辑，会非常吃亏。AI 在企业级应用里的作用是“辅助业务处理”，前提是你得先懂业务处理本身。建议先掌握至少一到两个 SAP 核心模块的端到端流程，再去看 AI 在这些流程里如何嵌入。
6.4 建立“SAP+AI”的复合知识体系
单纯懂 SAP 的人很多，单纯懂 AI 的人更多，但既理解 SAP 业务流程又能落地 AI 方案的人很少。具体来说，可以从这几个方向积累：
- 理解 SAP 的数据模型，知道哪些表存储了关键业务数据；
- 理解 SAP 接口协议，比如 RFC、OData、SOAP 的调用方式；
- 理解 AI 服务的基本调用方式，包括认证、限流、错误处理；
- 理解 RAG 的基本原理，知道企业知识库怎么建设和维护；
- 理解提示词工程在企业场景里的局限，知道什么时候模型会“一本正经地胡说八道”。
这套知识体系不一定要求你成为 AI 算法专家，但足以让你在企业级 AI 项目里成为“能落地的那个人”。
7. 常见疑问与排查思路
围绕 SAP 和 AI 成本，技术社区里已经有一些代表性疑问。这里统一整理成表格，便于快速查阅。
| 疑问 | 分析 | 应对方向 |
|---|---|---|
| SAP 暂停差旅招聘，是不是说明 AI 方向不看好？ | 不完全是。更合理的解读是 AI 投入进入预算硬约束阶段，企业要求 AI 功能证明投资回报率。 | 关注 SAP 官方后续发布的产品路线图，看哪些 AI 功能被加强、哪些被弱化。 |
| SAP 的 AI 功能会不会让我失业？ | 短期看，AI 减少的是重复性操作的时间，而不是岗位；长期看，不理解 AI 的顾问会更被动。 | 把 AI 工具纳入自己的工作流，从“会用”到“能判断 AI 结果对不对”。 |
| AI 成本会一直这么高吗？ | 模型推理成本整体呈下降趋势，但企业级数据的接入、合规、定制成本不会快速下降。 | 在项目设计阶段就把成本控制纳入架构，不把所有 AI 功能都做成“实时+完全自动”。 |
| 现在还要不要学 SAP？ | SAP 的核心 ERP 业务仍是企业数字化底座，需求不会消失；但纯配置型技能会贬值。 | 学 SAP 时一定要叠加数字化和 AI 能力，避免只会“点配置”。 |
| SAP 项目里 AI 调用失败怎么排查？ | 常见原因包括权限不足、模型服务限流、数据格式错误、网络策略限制。 | 先看 SAP 接口日志，再看 BTP/AI 服务侧日志，最后检查认证凭据。 |
以 AI 调用失败为例，比较稳妥的排查顺序是：
- 确认调用方用的服务账号有没有权限；
- 确认请求参数是否满足 AI 服务的约束条件，比如最大 token 数、字段格式；
- 确认是否有网络策略拦截了 SAP 系统与 AI 服务之间的通信；
- 查看 AI 服务返回的错误码，是限流、鉴权失败还是模型推理异常；
- 在测试环境用最小请求复现，逐步增加字段，定位具体触发条件。
这种排查思路和传统 SAP 接口联调非常相似，只是多了一层模型服务和平台配置。
8. 总结：AI 高成本时代，技术人真正该关注什么
SAP 暂停大部分差旅和招聘这件事，从一个侧面印证了生成式 AI 在企业级软件里已经从“概念验证”进入“财务核算”阶段。对做 SAP 生态的技术人来说，真正有价值的动作不是预测 AI 什么时候会取代谁，而是理解 AI 成本的结构、理解 AI 与业务结合的方式，并且在自己的项目里把这个结合做好。
后续可以持续关注几个方向：
一是 SAP BTP 上 AI 服务的定价和计费方式变化，这会直接影响企业级 AI 功能的成本评估；二是 SAP 官方对 Joule 等生成式 AI 功能的产品定位，看它是成为独立产品，还是作为各业务模块的内置能力；三是企业客户在 SAP 项目里真实落地的 AI 场景，关注哪些场景 ROI 最高、哪些场景叫好不叫座。
AI 带来的改变不是“系统能不能聊天”，而是“企业能不能用更低成本、更高质量地完成业务决策”。这句话，放到 SAP 的世界里同样成立。
