企业官网建设流程全解析

从去年开始，企业软件圈子里一直有一个隐约的焦虑：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 投入，就处在这样一个“不得不做”的阶段。

这张表的价值在于：如果企业还在用“传统 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 场景的成本模型至少包含六项：

这里有一个非常典型的误区：很多人只算模型调用费，觉得一个月几千块很便宜。但真正的成本大头是按人天计的开发和治理费用，以及 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( users=50, calls_per_user_per_day=10, avg_input_tokens=2000, avg_output_tokens=500, price_per_million_input=15, price_per_million_output=60, ) 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": f"Bearer {API_KEY}", } resp = requests.post(API_URL, headers=headers, json=payload, timeout=30) 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, mode="r", encoding="utf-8-sig") as fin, \ open(output_path, mode="w", encoding="utf-8-sig", newline="") as fout: reader = csv.DictReader(fin) fieldnames = reader.fieldnames + ["ai_category"] writer = csv.DictWriter(fout, fieldnames=fieldnames) 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"] = f"ERROR: {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 项目的实施经验，下面几个坑最常见。

这七条里面，主数据质量是 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 顾问，答案取决于你把它当成对手，还是当成工具。