SAP:把企业的「操作系统」带进 AI 时代

Philipp Herzig 是 SAP 首席技术官，负责这家拥有 40 万企业客户的巨头的 AI 战略与技术转型。这场对话来自 No Priors 播客，主持人是知名风险投资人 Sarah Guo。

在这场对话里，Philipp 谈到了几个与主流叙事相悖的判断：大语言模型根本不适合做需求预测；企业 AI 最难的部分不是模型本身，而是 20,000 个 API 的集成；以及为什么”创新竞赛”和”成果竞赛”之间的鸿沟正在越来越大，而不是越来越小。作为全球最大的企业软件公司，SAP 正在三个层面同步重构自己：用户界面、业务流程和数据层。

SAP 凭什么穿越五十年技术周期而不倒

SAP 成立于 1972 年，起因是几位 IBM 工程师意识到为每一位客户定制财务系统在经济上毫无可行性。他们提出了”标准化软件”的概念：把所有公司都需要的财务、人力资源、供应链流程抽象成一套可复用的系统，一次构建，反复部署。这个想法活到了今天，让 SAP 服务于全球 40 万家企业，成为市值最高的企业软件公司。

Philipp 把 SAP 描述为企业的”操作系统”——它不只是一款软件，而是支撑着从下单到收款、从采购到付款、从招聘到退休的每一条核心业务流程。正因为它嵌入得如此之深，每当新的技术浪潮到来，SAP 不是被替代，而是成为新技术的承载者：从大型机到客户端-服务器，从互联网到移动端，现在是 AI。

他的核心判断是：技术一直在变，但企业对”业务成果”和”投资回报”的需求从未改变。SAP 的长青秘诀不是技术领先，而是始终紧盯这个永恒的需求，并不断重新设计系统来满足它。每一次技术转型，SAP 的问题都是同一个：如何用最新的技术，帮助客户更高效地完成他们的工作？

这个判断对 AI 时代同样成立。当整个行业在讨论”哪个模型更强”，Philipp 的关注点始终是：有没有帮客户节省成本、加快决策、提升供应链韧性？他在对话里说，他从不在客户面前卖技术——无论是和 CFO 还是 CIO 开会，第一个问题永远是”你们目前面临什么业务挑战”，然后才是倒推技术方案。

创新竞赛 vs 成果竞赛：为什么大多数 AI 项目卡在了中途

Philipp 用了一个精准的框架来描述当前企业 AI 采用的困境：所有人都在参加”创新竞赛”，但真正重要的是”成果竞赛”。创新竞赛关乎新技术的兴奋感——在 10 份文档上搭一个概念验证 RAG 聊天机器人，让 CEO 眼前一亮，非常容易。成果竞赛关乎真实的业务价值——在复杂的企业环境里大规模部署，真正替人做决策、省成本，极其困难。

他的观察是，这两场竞赛之间的鸿沟正在扩大，而不是缩小。原因在于规模：10 个文档不是问题，100 个文档开始棘手，1,000 个文档是真正的工程挑战。而 SAP 的客户动辄拥有 20,000 个 API，这不是规模的量变，而是质变。他举了一个具体的例子：当员工询问差旅报销政策，系统需要知道他的所在地、归属薪资体系、适用的税务管辖区，才能给出正确答案——这和在 10 个文档上做聊天机器人完全不是一个问题。

安全是另一道坎。他提到，最近发生了一个 LLM 相关框架的漏洞事件，导致大量密钥和凭证被窃取。对于任何一家企业的首席信息安全官来说，这类事件意味着他们无法直接把开源的 AI 工具部署进公司，必须构建完整的安全层。这些隐性的基础设施成本，往往不在 AI 的 Demo 里出现，却是规模化落地时绕不开的障碍。

这个判断对创业者和产品团队都有意义：Demo 阶段的成功和生产阶段的成功之间有一道极高的墙。那些低估了规模化难题的团队，往往在概念验证阶段获得了大量掌声，却在真正落地时卡住。Philipp 的建议只有一条：从业务挑战出发，而不是从技术出发。如果获取价值的时间太长，商业案例就会瓦解。

大语言模型根本做不了预测：SAP 为什么要发明 RPT1

这是 Philipp 在对话中最反主流的观点：大语言模型在企业里被大量鼓吹，但它根本不适合做预测分析。他的逻辑很清晰：LLM 本质上是在做序列到序列的 Token 生成，这个架构非常适合处理非结构化数据——文本、图像、知识问答。但企业最核心的决策依赖是预测：需求预测、现金流预测、付款延迟预测。这些都是结构化的表格数据问题，本质上是回归和分类问题，LLM 并不是为此而生的。

传统的解法是 XGBoost、AutoML 等机器学习方法，但这些工具有一个巨大的问题：无法普及。它们需要专门的数据科学家，需要大量数据，需要为每个场景单独训练模型。他举了一个真实案例：一家制药公司在全球 90 个国家做付款延迟预测，最终需要训练 180 个独立模型，每个都需要数据工程、特征工程、模型调优——这是一条根本无法规模化的路径。而且在零售业，预测某款商品在特定门店的季节性需求，需要结合历史销售、促销周期、天气因素等大量变量；在制造业，安排生产计划需要精准预测未来三个月的零件需求——这些都是 LLM 无法胜任的任务。

为了解决这个问题，SAP 研究团队历时两年，在 NeurIPS 等顶级学术会议发表了成果：RPT1（Relational Pre-trained Transformer，关系型预训练 Transformer）。它借鉴了 Transformer 的架构，但专门为结构化的关系型数据而构建——不需要大量数据，只需少量上下文就能做出高精度的分类、回归和时间序列预测，无需为每个场景单独训练模型。Philipp 认为，这将让普通业务用户也能做过去只有专业数据科学家才能完成的预测工作，是企业预测分析领域的一次真正的范式转移。

代理编码让”测试驱动开发”终于真正流行起来

Philipp 分享了一个有趣的观察：代理编码（Agentic Coding）正在把一个老概念重新带回主流——测试驱动开发（TDD）。他说，他读大学时，Google 的工程师来讲座，告诉大家因为先写了测试，所以每天下午五点就能下班。当然，这从未真正实现。测试驱动开发一直不受欢迎，原因很简单：先写代码更有趣；需求通常很模糊，你只能在写代码的过程中才能搞清楚系统应该怎样表现。

但现在，代码编写本身已经高度自动化了。代理编码之所以效果好，有一个根本原因：可验证性——你可以检查程序是否编译通过，单元测试是否通过，结果是否符合预期。这种可验证性让模型可以快速迭代和自我修正。问题随之而来：你现在需要真正把”预期结果”描述清楚——边界条件、安全要求、数据隐私、代码质量标准，因为这些就是智能体工作的依据。开发者的核心工作，从”写代码”变成了”定义正确性的标准”。

他特别指出，这种转变在金融等高风险领域尤为关键。在财务系统里，一笔错误的账务入账可能导致合规问题，你必须明确定义：给定这个输入，预期的正确输出精确到分是什么？这就是评估指标（Evals）的核心价值——它们不只是测试工具，而是让代理编码在敏感领域变得可靠的前提条件。这和他对 LLM 局限性的判断一脉相承：任何需要高精度、可验证成果的领域，都需要比”让模型猜猜看”更严格的约束框架。

生成式 UI：界面不再是被操作的工具，而是主动汇报的助手

Philipp 描述了企业软件用户界面正在发生的根本性转变。过去，软件设计的核心工作是：想办法设计一个尽量直观的 UI，让用户通过点击菜单和表单完成任务。经典的企业软件开发中，团队会做用户调研，找到最合理的操作路径，把复杂流程拆成可点击的步骤。这个范式已经过时了。他们称新方向为”生成式 UI”——界面不再是预先设计好的，而是根据用户意图动态生成的。

更深刻的转变是，系统从”被动响应”变成了”主动汇报”。过去，你需要打开系统，找到正确的报表，点击筛选条件，才能发现问题。现在，系统可以彻夜运行，分析数据，早上醒来主动通知你：供应链出现了一个问题，这是影响分析，这里有三个推荐行动方案。系统不只是你操作的工具，而是一个帮你盯着业务的智能体。

他举了一个具体场景：如果你是石油天然气客户，关税政策突然变化，你想知道这对供应链意味着什么。过去，你需要找业务分析师、等他整理数据、给你出一份 PPT——而且 80% 的情况下仪表盘里的固定报表够用，但剩下 20% 的非标准问题，你只能去找 IT 部门重新开发。现在，你可以用自然语言直接问 SAP 系统，它结合你的真实供应链数据和外部政策信息，给出分析和可选方案。系统把自然语言转换成 SQL 查询、拉取数据、生成洞察，让你在几分钟内得到一份定制化的分析。这种能力在过去二十年几乎是不可能实现的，而现在正在变成企业软件的标准形态。

智能体挖掘：把”部落知识”变成持续优化的数据飞轮

Philipp 介绍了一个他认为非常重要但尚未被广泛讨论的概念：从”流程挖掘”到”智能体挖掘”的演进。流程挖掘是通过分析系统日志，了解业务流程在系统里实际是怎么运转的——比如一笔应付账款从审批到付款实际经历了哪些步骤、在哪里延迟了。这是 SAP 做了多年的事情。而智能体挖掘走得更远：它记录的是决策轨迹——当 AI 智能体与用户交互时，它提出的澄清性问题、用户的选择、以及背后的上下文，都被完整记录下来。

这件事的价值在于它能捕捉”部落知识”——那些存在于人脑里、Slack 频道里、或者电话里的隐性知识，这些从未被存入任何系统。比如，某个团队处理特殊付款情况时有一套自己摸索出来的更快捷的流程，但这个方法从未被写进标准操作手册。现在，当智能体引导用户完成这类任务，用户的输入被完整记录，这套更好的做法就能被识别出来。

通过分析这些轨迹，系统可以发现两类情况：异常（某个团队的做法偏离了标准，需要纠正）或改进（某个团队的做法比标准更好，值得推广）。如果是改进，可以把它提升为全球新的标准作业程序，让全世界的团队都受益。这构成了一个数据飞轮：每一次交互都产生新数据，让系统不断优化，服务下一个用户时更准确。从某种意义上说，每一个使用系统的人都在无意识地帮助训练下一代的系统，让整个组织的决策水平持续提升。

从按座位到按成果：企业软件商业模式的下一次革命

Philipp 对企业软件商业模式的演变持有清晰的判断：方向是确定的，路径是渐进的。当前 SAP 的软件主要采用按座位授权的模式，但随着 AI 的深度嵌入，他们正在向消费型（按使用量付费）过渡。更长远的目标是成果导向型定价——你为实际产生的业务价值付费，而不是为软件的使用权付费。他提到 Sierra 等新兴 AI 服务公司的做法作为参考方向。

但他对节奏保持冷静。短期内，纯粹的消费型或成果型定价对大多数企业客户来说还无法接受，原因有二：可预测性需求（他们需要控制成本，无法承受消费激增的风险），以及信任缺口（他们还没有建立对 AI 驱动成果的足够信任）。因此 SAP 目前采用混合模式，兼顾未来方向和客户当下的现状。他说，他的客户群非常多样——有些很前卫，有些仍然需要传统的授权模式——这决定了变革的节奏必须是渐进的。

他把成果导向型定价的前提条件说得很清楚：可验证性。只有当系统的输出足够可靠、可测量，才能合理地把定价与成果挂钩。这反过来解释了为什么评估框架、智能体挖掘、以及对 LLM 局限性的清醒认识都如此重要——它们不只是技术决策，而是通向下一代商业模式的基础设施。商业模式的转型，归根结底需要技术的可靠性先走到位。

AI 不是在消灭财务和供应链岗位，而是在给它们”升级”

Philipp 对”AI 会不会让企业裁员”这个问题持有清晰但不悲观的立场。他的判断是：AI 不是在消灭这些岗位，而是在把它们整体提升一个层级。他用了一个类比：今天在财务共享服务中心做数据收集和报表整理工作的人，类似于今天使用 Claude Code 的初级开发人员。初级开发人员不再把大量时间花在写基础代码上，而是开始监督代理生成的代码、提供反馈、思考架构设计。财务人员也会经历同样的转变。

他描述了这种转变的具体形态：那些原本花大量时间收集数据、整理 Excel、准备 PowerPoint 的工作会被自动化。AI 会彻夜运行、整合多个数据源、生成分析草稿。人的工作变成：运行更多情景分析，对 AI 生成的洞察进行判断，做出更具战略性的决策。他说，人们将能够以更快的速度获得更好、更深入的洞察，从而”真正进行战略性思考”——而不是把时间耗在信息搜集上。

他还提到了 SAP 自己的产品案例：他们在咨询服务领域推出的 Joule for Consulting，能够帮助顾问应对复杂的 SAP 项目，让工作量减少约 30%，更快地帮助大型企业完成云迁移和 AI 能力升级。差旅预订和费用报销智能体也已经在 Concur 产品线上线，自动化了过去需要大量人工处理的费控流程。这些不是把人替代掉，而是把人从繁琐的执行工作中解放出来，让他们专注于判断、创意和那些真正需要人类智慧的部分。

量子计算：供应链优化问题的终极出路

除了 AI，Philipp 提到了他个人正在持续关注的另一个领域：量子计算。他的判断是，一旦量子硬件成熟，它将解锁一类当前计算机只能”近似处理”的问题——组合优化问题。

对 SAP 而言，这类问题无处不在：供应链里的旅行商问题（如何规划卡车路线让总成本最低）、背包问题（如何在有限载重下最大化货物价值）、复杂的仓储和物流调度。这些问题理论上有精确解，但在现实规模下，经典计算机在合理时间内只能找到近似解。如今我们接受的是”在有限时间内能得到的最优解”，而不是真正的最优解。量子算法有潜力把这类优化的质量提升几个百分点——在大规模供应链里，这意味着数以亿计的成本节省和相当可观的碳排放减少。

他的态度是务实的：量子硬件还没有成熟，但等硬件成熟了再去研究算法就太晚了。SAP 保持硬件中立，现在专注的是在智力层面尽早理解和发展这些算法，当硬件准备好的那天能立即付诸实施。这和他的整体方法论是一致的——不追逐当下的技术热点，而是紧盯那些真正能为客户带来业务价值的问题，提前布局。量子优化之于供应链，就像 RPT1 之于需求预测：在大多数人还没意识到问题存在的时候，已经在为解法做准备。

结语

Philipp Herzig 这场对话的核心，是一个贯穿始终的判断：AI 时代真正的挑战，不是找到最好的模型，而是把模型嵌入真实的企业环境并产生可测量的成果。创新竞赛容易打，成果竞赛极难赢；LLM 能力惊人，但预测分析需要另辟蹊径；规模化部署的关键障碍是数据孤岛、安全合规和集成复杂性，而不是模型本身。

这场对话里有一个细节值得回味：Philipp 说他每天除了与团队评审项目，还在运行大量命令行实例做原型测试，”看看哪些有效，哪些无效，然后把这些作为灵感回馈给团队”。一个负责 40 万家企业客户的大公司 CTO，依然亲自跑实验。这和他对技术的整体态度是一致的——不是从高处宣讲，而是真正在一线感受边界在哪里。

从 SAP 五十年的历史来看，这个判断有更深的意涵：真正经久不衰的企业软件，不是那些追逐每一波技术浪潮的，而是那些始终盯着”客户到底要什么成果”这个问题、并不断用新技术来更好地回答它的。技术会变，商业需求不会。让技术”隐形”，让成果”显现”——这是 SAP 五十年来的核心逻辑，也是 Philipp 认为 AI 时代所有企业软件公司都应该遵循的判断框架。

内容来源：”SAP: Bringing the ‘Operating System’ of a Company into the AI Era with CTO Philipp Herzig”丨No Priors Podcast