SAP TechEd柏林观察：企业AI如何发挥飞轮效应? 原创

这个星期，我在柏林参加了SAP TechEd大会。

这是一场面向企业级应用的开发者活动，但AI毫无疑问是"最靓的仔"，无论是SAP发言人的主题演讲、产品演示，还是交流互动环节，均围绕这一主题展开。毕竟主讲人不讲，台下听众也会问。

Day 1主题演讲结束后，SAP执行董事会成员Muhammad Alam、SAP业务技术云总裁Michael Ameling和SAP CTO Philipp Herzig接受了全球媒体的提问。

我借这个机会，提出了企业AI落地中一个颇为常见的问题：许多企业CEO对AI转型高度关注，希望快速见到成效，但技术团队在实施过程中往往面临诸多挑战，难以达成目标，SAP如何看待这一问题。

Alam说，他们观察到一种非常常见的现象是，很多组织为了应对AI变革，会建立专门的AI团队，设专职人员推动AI项目。然而这一角色往往与负责数据战略的人员相分离，在大多数情况下，也与负责应用战略的团队各自独立。

这种组织架构看似美好，却会导致孤岛效应。

我想了一下，确实有道理。因为如果AI团队、数据团队、应用团队各自为战，企业就要持续在内部 "数据搬运"，这一定会导致效率瓶颈。类比一下，GPU集群在训练模型的时候，也要避免"数据搬运"啊。

当然，SAP不仅提出问题，也负责解决问题。

针对企业AI落地，SAP CEO Christian Klein在今年Sapphire大会上提出了一个 "App（应用） + Data（数据） + AI"的业务飞轮。其中，应用，数据，AI，这三者如果在统一架构内协同运作，就会形成一个自我强化的循环。

用Alam的话说：在AI时代，真正的差异化在于如何为组织创造端到端的业务价值。这只有在你简化和创新核心，而不是在IT环境中增加另一层复杂性时才能实现。

而根据我在柏林两天时间里在TechEd上观察到的SAP技术发布，核心似乎正是围绕这一飞轮的构建。从HANA Cloud到Business Data Cloud，从SAP-RPT-1到Joule，所有产品发布均指向同一目标：消除数据、AI、应用之间的割裂。

但在深入细节之前，有一个概念，值得我们提前探讨，那就是ERP。

ERP的新角色

因为说到SAP的应用，必然绕不开ERP。所以，当我有机会采访SAP Business Suite总裁兼首席产品官Manoj Swaminathan时，马上问了他，ERP是否会有新角色？

他给了一个肯定的答案。具体而言：传统ERP遵循的是"记录-发布-报告"的逻辑，记录交易、发布凭证、生成报表。这个模式运转了几十年，但本质上是被动的。

但在飞轮的驱动下，ERP的工作方式正在发生转变。Manoj用三个词描述了这种转变：感知、推理、行动。

系统首先要能感知内外部变化，比如汇率波动、利率调整、通胀趋势等。然后基于数据推理并生成建议。最后在可信的人机协同中实现自动化行动。

而这恰恰需要飞轮的完整循环：感知需要数据不只是"存在"，还要"可理解"；推理需要AI能真正理解业务语义；行动需要智能体能跨系统协调，但人类始终保持控制。

现在业内有一种观点，有了模型和数据，可能不再需要产品。但Manoj特别强调：应用依然是企业的基础。AI无法在没有业务语境的情况下提供真正的智能。

而且他强调了统一"套件"的价值。企业若使用不同的系统，整合数据时就会丢失业务语义(Business Semantics)，AI也无法提供有意义的建议。

这句话很关键。它也顺带解释了为什么SAP要强调"飞轮必须在同一个架构里转"。不是为了技术上的整洁，是为了保留上下文。

所以，接下来，我们谈谈SAP的数据观。

让数据"活"起来

众所周知，AI有算法、算力、数据三要素。但对企业落地AI而言，其实在算力、算法方面能做的有限。因为算力由负载决定（当然，有优化空间），算法更多由模型公司决定，但数据是企业自己能掌握的。

因此，要让飞轮转起来，第一步就要解决数据问题。SAP 业务数据云总裁Michael Ameling在主题演讲中也开宗明义：几十年来，数据一直在推动创新。但随着AI的出现，数据比以往任何时候都更加重要。问题在于，数据往往是沉默的，缺乏所需的上下文。因此，AI无法充分发挥其潜力。

SAP的答案是HANA Cloud：一个"AI一直在寻找的数据库"。

这个2009年就开始研发的内存数据库，现在已经是数万家企业的IT基础设施。但它的价值不在于速度，而在于多模型能力。Ameling解释说：如果没有HANA Cloud，你将需要为每一种数据表示形式配备一个独立的数据库。比如：一个用于列式存储，一个用于向量，一个用于知识图谱。这就会导致数据科学的分散化。有了HANA Cloud，就能将所有这些强大的引擎整合在一个多模型数据库中。

反之，实现了数据组合，就让HANA Cloud不只是一个"存储数据"的地方，而是一个"理解数据"的引擎。

会上有一个实际的案例：某上游供应商的外勤销售人员过去很难获取定价信息。但现在使用HANA Cloud的向量引擎开发了一个AI定价助手，结果销售订单录入的自动化率大幅提升，订单错误率反而下降几成。

但更重要的新能力是"发现智能体"(Discovery Agent)。Ameling说：过去使用HANA的高级功能需要深厚的专业知识，大家都知道要写SPARQL查询有多难。现在，发现智能体可以帮助用户即时找到数据库中正确的数据对象。过去需要进行大量专家访谈和深入挖掘，现在几秒钟就能完成。

在大会第二天的技术演示中（顺便说，Day 2 的主题演讲全是Demo，下边我附了演示团队结束的合影），一位工程师展示了这个能力。他激活了HANA中的Triple Store功能，创建了一个关于TechEd演讲者的知识图谱，然后用自然语言提问："哪个演示将展示应用编程模型，谁能展示它?"

大语言模型自动生成SPARQL查询，从知识图谱中检索出答案：演示标题是"SAP CAP、MCP和AI智能体"。整个过程行云流水，没有手写代码。

更进一步，HANA Cloud将能够自动扫描所有元数据，实时生成知识图谱，并且"随着数据模型的演进而保持同步"。Ameling强调：它还将允许通过MCP(Model Context Protocol)将数据库对象"表、视图、数据图"作为工具来使用。这使得智能体能够在端到端应用程序中无缝地与HANA的高级功能进行交互。

最后是"智能体记忆"功能。因为智能体需要记住任务、对话和决策作为上下文实现长期记忆，变得更加智能。

HANA Cloud的这些能力，解决的是飞轮的第一个问题：让数据不只是"存在"，而是"可用"、"可理解"、"可记忆"。

内联外通：让语义不再丢失

不过，显然企业光有一个强大的数据库还不够。因为企业的数据可能分散在各个系统。有SAP自己的应用，有Snowflake的数据仓库，也有Databricks的数据湖等等。

所以，如何把这些数据统一起来，同时保留业务语义?

这正是Manoj所说的关键挑战。他在采访中特别强调："企业若使用不同厂商的系统，整合数据时就会丢失业务语义，AI也无法提供有意义的建议。"

SAP的答案是Business Data Cloud(业务数据云，BDC)。

大会上的一个重磅消息是SAP宣布和Snowflake合作。这看起来是一个常规的生态合作，但实际上暗含了SAP战略的一个信号：不要求客户把数据都搬到SAP的平台上，而是让SAP的数据能力可以"接入"到客户已有的数据平台。

在大会Q&A环节，有人问Alam是否会继续扩大BDC的合作伙伴。他的回答也很明确：这是SAP从生态系统角度保持开放性的承诺。我们有一长串的合作伙伴都很高兴能够参与BDC的发展，无论是从数据共享的角度，还是在其基础上构建应用程序。

BDC的核心价值在于统一语义层。Ameling解释：BDC能通过协议实现零复制数据访问。这意味着数据可以留在原地，无论是在S/4HANA、Snowflake还是Databricks等。但是，所有系统都能理解这些数据的业务含义。

更重要的创新是Data Products Studio。这个新工具让开发者可以把原始数据"打包"成带有业务语义的"数据产品"。

什么是数据产品?简单说，就是把数据从"表格"变成"API"。一个数据产品不只包含数据本身，还可能包含：

业务语义：如这个字段是"客户满意度"，不只是一个数字

数据血缘：这个数据来自哪里，经过了什么处理

访问权限：谁能用，怎么用

版本控制：数据定义变化时的向后兼容

在演示环节，SAP工程师在几分钟内就把来自S/4HANA的销售数据和来自Snowflake的市场数据融合成了一个"客户洞察数据产品"，设置了版本和权限。这个数据产品可以被不同的应用、AI模型直接调用，不需要重复做数据准备。

这种做法的好处是显而易见的：数据团队不再是"服务台"，被动响应各种需求，而是可以主动构建可复用的数据资产。对AI团队来说，他们不需要每次都从零开始，直接调用现成的"数据产品"就行。

Ameling总结：SAP业务数据的一个关键组成部分是智能应用。这些应用具有自适应性和AI驱动能力，它们从数据中学习，在分析和协同工作中实现自动化。而在幕后，智能应用是由数据产品驱动的。

为什么表格需要自己的AI

飞轮已经有了数据层和语义层，接下来需要的是AI的分析能力。

这里有一个没有被忽视，但是一直存在的悖论。说到AI，就会说到大语言模型，它们很擅长处理文本，但企业的关键数据大多在表格里，有订单、库存、财务报表等。

于是，我们看到了SAP的SAP-RPT-1（读音：RapidOne）。

SAP CTO Philipp Herzig在介绍这个模型时，先问了台下一个问题：如果老板要你用机器学习解决10个业务预测任务，分别针对公司的10个不同业务实体，需要训练多少个模型?

他停顿了一下，然后说答案可能是上百个，每个任务要针对每个实体单独训练。但你训练完两个之前，老板就会来问ROI了。

讲到这，台下一片笑声。

这就是传统机器学习在企业场景的困境：每个预测任务都要单独训练模型，成本高、周期长、难以扩展。

SAP-RPT-1要解决的也就是这个问题。它是一个专门为表格数据设计的关系型基础模型。它不预测"下一个词"，而是预测"业务结果"，包括订单会不会延迟、客户会不会流失、库存应该补多少。

Philipp在另一场采访中说，两年前SAP经内部讨论，做出了不会自建大型语言模型的决定，而是专注于SAP独有的结构化数据。

而SAP-RPT-1是一个针对表格数据的基础模型，用于预测付款延迟、供应商风险、销售机会等典型业务任务。

他说，这个模型在德国和帕洛阿尔托的研究团队开发，论文已与斯坦福大学合作发表。模型采用"跨表图变换器(Cross-table Graph Transformer)"架构，能在多表关联中进行预测。

在Q&A环节，有记者追问性能。Herzig给出了更多细节：实验结果显示，它不仅优于通用大模型，也超过一般机器学习模型，在公开基准测试上的表现已经超过了一些传统方法。

不过他也很坦诚：我们也期待看到它在不同企业场景中的实际表现。这就是为什么SAP提供了免费试用环境。

这就是飞轮AI层的核心能力：除了SAP已经集成连接的LLM，还有专门为企业结构化数据设计的预测模型。

从助手到执行者

飞轮有了数据基础，有了AI的分析能力，接下来需要的是执行层——让AI的洞察真正转化为行动。SAP的Joule就是做这件事情的。它是一款嵌入 SAP 各类云产品的生成式 AI 助理，将大模型能力与企业业务流程深度融合，让用户能以自然语言完成数据分析、任务执行与决策支持。

但这里需要澄清一个容易混淆的概念：我们不应该把Joule看作"应用"，而是AI的交互界面和智能体编排平台。

SAP CEO Christian Klein此前讲过：Joule是成为SAP新的前端，新的用户体验。它坐在所有应用之上，是人与AI系统交互的界面。

过去一年，SAP已经发布了多个Joule智能体，覆盖财务、供应链、人力资源等领域。

但对我来说，更有说服力的是SAP CTO Philipp告诉我的另一组数字。在一场QA环节中，他在回答我"SAP内部是如何使用AI的"的问题时就用Joule举了例：

"Joule在SAP内部的月活用户已超过3万"，"系统中存储了超过10万份多语言政策和文档。员工无论在巴西、非洲还是德国，Joule都能自动匹配适用的人事或差旅政策。"

他还讲了一件很有趣的事，在SAP内部， Joule的"杀手级应用"第一名是采购流程，但第二名不是复杂的报表分析，而是"查午饭菜单"。SAP IT部门为此开发了一个定制技能，员工每天可以直接问Joule：今天午餐吃什么?（看来中午吃啥这件事儿，是一个世界难题啊）

不过，我想这听起来很轻松，但也体现了AI真正融入工作流的意义：当人们每天自然使用它，AI才算落地。

Philipp说，根据SAP内部统计，Joule的差评率(Thumbs Down Rate)仅为1%。这说明在真实的企业使用环境下，它已经足够可靠。

这些内部数字，自然比任何demo还有力量。

虽然SAP提供了现成智能体，但是也在推动客户自己构建智能体。SAP的Joule Studio，就是为这个目的设计的。

让飞轮转起来需要什么

但飞轮再好，如果开发者用不起来，也只是空中楼阁。SAP在柏林做的另一件重要的事，是统一开发者体验。

第二天的开发者主题演讲，让人印象深刻的是：在VS Code里无缝开发SAP应用。

过去，开发不同类型的SAP应用要用不同的IDE：ABAP要用ABAP Development Tools，UI5要用SAP Web IDE，低代码要用SAP Build。开发者要在多个工具之间切换，学习成本高，效率也低。

现在，SAP把这些能力都整合到了VS Code里。更重要的是，通过MCP服务器，开发者可以用Cursor、Claude Code这些AI编码工具来写SAP应用——AI助手能理解SAP的开发框架、数据模型、业务逻辑。

演示中，一位工程师展示了整个流程。他打开VS Code，在终端里敲了一行命令创建了一个项目，然后用自然语言对Claude说："我需要一个应用，当SuccessFactors里新增员工时，自动触发一个审批流程。"

Claude AI通过SAP的MCP服务器理解了需求，生成了完整的代码，包括事件订阅、工作流定义、UI界面。工程师稍微调整了一下UI的颜色，整个过程只有数分钟。

当然，这个demo经过了精心准备，实际开发肯定还需一番功夫。但它传递的信号很明确：SAP希望开发者用自己熟悉的工具、自己喜欢的方式来开发，而不用锁定在SAP的工具组合中。

Manoj在接受我的采访时也提到，有了AI的助力，开发人员的角色也更加丰富。

SAP同时支持专业代码与低代码/无代码。业务人员可以直接在UI中使用SAP Build扩展功能，比如在采购订单界面添加字段，无需复杂编程。这让业务团队能独立完成轻量开发，IT团队则聚焦核心系统。

再补充一个细节，SAP在会上展示两个看似小的功能，可能在企业内部会有大用：

Prompt Optimizer（提示优化）：自动把为某个模型写的提示词转换成适配其他模型的版本。

Eval Service（评估服务）：跨模型测试和比较AI用例的效果。

早期客户的测试显示，通过提示词优化，在相同成本下可以获得30%的性能提升。

这些工具的核心思路都是一样的：把AI的使用从"玩票"变成"工程实践"。有评估、有版本管理、有自动化优化，而不是凭感觉调参数。

一体化还是最佳组合？以及SAP的护城河

回到最开始我提的问题：CEO们很焦虑，技术团队很迷茫，怎么办？SAP给出了自己的答案。

同样，整个产业都在重构，SAP的护城河在哪里？

我理解，SAP给出的就是一种架构级的方案：不要把AI当成一个独立的项目，而要把数据、AI、应用作为一个整体来思考。HANA Cloud提供AI-native的数据基础，BDC构建开放的数据生态，RapidOne处理结构化数据的预测任务，Joule执行智能体编排，开发者工具让这一切易于使用。

这个方案是否成功，取决于一个更根本的判断：企业AI的未来，到底是"最佳工具组合"还是"一体化平台"?

如果是前者，那么企业会继续在不同场景下选择不同的最佳工具。这种情况下，集成和互操作性就是最大的挑战。

如果是后者，那么像SAP这样能提供端到端解决方案的平台就有巨大优势，数据、AI、应用都在一个架构里，不需要做复杂的集成工作。

SAP的战略布局，就是押注企业会在核心业务场景里选择一体化方案。我与一位SAP同事交流时，对方给了我一个颇有说服力的比喻，"早年间，大家身上会带不同的数码设备，随身听，照相机，PDA等等，但是iPhone这样的产品一出来，大家很快选择了All In One。"

而对于现在市场上随LLM出现了很多原生企业应用的景象。Manoj在采访中谈及SAP优势时也给出了一个很有意思的论证：SAP有50年的企业软件经验和庞大的客户群。AI原生公司缺乏最关键的东西就是真实的业务数据。以Concur为例，SAP在差旅和费用管理领域积累了丰富的数据网络，能提供其他公司难以企及的洞察。

这种数据广度与业务上下文的结合，让SAP能构建出开箱即用、语义完整的AI应用。这正是SAP的护城河。

在TechEd大会上，SAP没有回避关于当前AI是否一种炒作的疑问。但Philipp讲了一句话让人印象深刻：就像互联网早期发展一样，人们往往高估一年内，新技术能做的事，但是低估十年内它们能改变的事。AI的确有炒作的成分，但这次基础设施成熟得多，迭代速度也更快。真正的价值不会停留在硬件层，而会体现在最终用户体验上，那些人人可用、可持续付费的服务。