SAP：2026 年摩根士丹利TMT投资大会访谈全文
$SAP SE(SAP)$ 参加 2026 年摩根士丹利科技、媒体与电信大会
2026 年 3 月 3 日，美国东部时间上午 10:00
公司发言人
– Muhammad Alam - 产品工程负责人及执行董事会成员
会议主持人
– Adam Wood - 摩根士丹利研究部
问答环节
Adam Wood首先，最近有消息称你明年合同到期后将不再续约 SAP。我想知道你是否可以详细说明一下这背后的原因？
Muhammad Alam是的。我想不用透露太多细节，但我个人方面确实有一些事情在处理，这让我目前很难做出续约的承诺。根据德国的治理规定，一旦合同面临续约，必须提前一年进行相关讨论。而我当时的个人状态无法对此做出承诺。本着透明化的原则，我们认为向同事和外界沟通这一情况是正确的做法。
但是，听着，我对此的看法是：我的合同还有一年多才到期。正如各位所知，在当今的环境下，一年的时间足以产生非常深远的影响。这也是我们目前的工作重心，无论是对 SAP 内部还是对我们的客户而言。
Adam Wood祝愿你在接下来的 12 个月里一切顺利，非常期待看到你带来的影响力。
昨天我在参加晚宴时，大家被问到本次大会的大主题以及最想获得的收获。我想现场有一半的人都在问：“我们该如何理解传统应用软件厂商的护城河？”这也是我想开始的话题，即所谓的“房间里的大象”——你们如何保护现有领地和护城河。你认为传统软件厂商在多大程度上受到生成式 AI（GenAI）颠覆的风险？你认为 SAP 最大的护城河是什么？
Muhammad Alam好的。听着，我认为首先必须承认生成式 AI 确实对现有的软件厂商产生了重大影响。这一点很明确，没人会对此争论。但我认为，在这个讨论中我们忽略了一点：并非所有的 SaaS 厂商或应用都是平等的，它们在客户环境中所扮演的角色也不尽相同。
确实，某一类 SaaS 应用会更容易受到风险、颠覆和转型的冲击，但也有另一类 SaaS 应用——从 SAP 的角度来看，我们深信自己属于这一类——它们对组织的运营具有极高的任务关键性（Mission-critical）。当你想到财务管理、总账、司库、应付账款、应收账款，再到供应链侧的工厂车间运行或物流环境时，那是完全不同的一类应用。
在我脑海中，这就像是一个对等的逻辑：市面上有各种应用，但如果你想到 Windows，它本质上也是一个应用，但它是消费者在设备上日常使用的“操作系统（OS）”。SAP 在很大程度上就像是企业的操作系统。
当然，上面构建了很多应用，我们的很多合作伙伴在做这件事，也存在大量的集成。但要替换掉这个“操作系统”是非常困难的。虽然你可以用生成式 AI 构建一个操作系统，但你会因此现在就开始自己写个 OS 来运行自己的设备吗？这未必现实。
但对于构建在其上的应用，以及客户自定义应用，生成式 AI 的确更易于发挥作用。从 SAP 的角度来看，即使是在我们深耕的应用领域，生成式 AI 也带来了前所未有的创造增值价值的机会，这也是我们的重心所在。我们相信被颠覆的风险性质是不同的。
我认为目前外界的讨论倾向于把所有 SaaS 应用混为一谈，这是最初的反应。但从根本上说，当我们与客户交流、审视我们的产品组合时，现实情况显得大不相同。
Adam Wood这正好引出了我的下一个问题：现在有一套既有的应用，也就是你提到的操作系统；但同时也有一个巨大的“空白地带（White Space）”，这是新技术能力开启的领域。首先，复制你所说的那个操作系统会有多难？其次，当你考虑进入空白地带，去自动化那些以前无法自动化的事物时，这套操作系统能带给你什么优势？
Muhammad Alam是的，这是个非常好的问题。让我们拆解一下这类应用及其独特之处，这正是问题的核心。如果你思考让这类应用与众不同的因素，那就是嵌入其中的长达 50 年的逻辑和业务流程。这不仅仅体现在我们讨论的横向领域（如财务、人力资本管理、采购、供应链等），还体现在深厚的行业能力中——比如我们在石油和天然气、制造业、媒体等行业所做的一切。
这种集体知识、围绕它的数据、对其语义的理解以及业务流程的定义，构成了一道屏障。不仅如此，作为一个企业级参与者，我们的历史是运行跨行业的最关键、规模最大的组织。我们所具备的企业级就绪度、治理、安全、隐私，以及我们在全球这么多国家实现的本地化，共同构成了这一护城河和准入门槛。这让别人很难说：“嘿，我要写个东西直接把它取代掉。”
这是一方面。所以，目前并不存在那种立竿见影的威胁，比如有人能迅速构建出一套总账系统，在全球范围内实现本地化，并符合所有法定要求。这种逻辑甚至存在于像 Concur 这样的产品组合中。我知道有人在讨论：“Concur 是不是更容易被颠覆？”
但如果你拆解 Concur 的业务，它是费用管理。费用管理在门外汉听起来很简单，但全球各地有海量的法定要求，我们投入了大量的研发力量来保持实时更新。当然，你可以创建一个基于数据的表单应用来记录费用，但谁来负责合规性？谁来长期维护？谁来确保它与核心操作系统的集成？
这就是为什么即使回顾过去 15 年，如果费用管理真的那么简单，这个领域早就泛滥了。但事实并非如此。因为即使在那里，从企业视角和本地化视角来看，依然存在护城河。话虽如此，这更多是防御性的门槛。问题在于，现在有了在之上创造巨大价值的机会，这才是我们深度关注的。
坦白说，回到你问我的第一个问题，让我感到有些遗憾的是，这是科技领域、业务应用领域一生难遇的机会，可以为客户创造非凡的影响和价值，从而为 SAP 和我们的股东带来价值。我们正全力以赴。
如果你思考之上的机会，自动化当然是重头戏。还有那种需要数据语境、流程语境和语境图谱（Context Graph）支撑的智能，它能随自动化而来，创造出自主化（Autonomous）的体验。
正如你所料，我们的 Sapphire 大会即将来临。我想大家都能预见到，我们将发布最雄心勃勃的产品：利用生成式 AI 和通用 AI 的可能性，将其置于核心操作系统之上。这套系统具备无可比拟的企业级就绪度、本地化广度和行业深度，从而创造客户所追求的价值。
我也喜欢打比方，再举个例子。如果你想到自主化应用，它不仅意味着自动化，还意味着内置的智能，以及能够完成人类无法大规模完成的任务，因为现在你可以跨海量数据进行操作。
但这种“自主化业务应用”的概念，与“自动驾驶汽车”并不完全一样。在这些核心的任务关键型应用中，你真的能买一套自主化软件装在一辆非自主化的车上，然后觉得“没问题，我要让我的车自动穿过小镇”吗？它不是这样运作的。应用、数据、智能体（Agent）和体验之间需要高度的无缝衔接，才能创造出那种难以通过外部拼接实现的非凡价值。
[Image comparing an autonomous vehicle system where software and hardware are integrated, vs a business application where data and AI agents are integrated]
在某些业务流程中你可以尝试这样做，但你必须意识到客户侧的总体拥有成本（TCO）影响。因为客户如果选择另一个 PaaS 供应商——现在人人都在做智能体 PaaS 平台，试图在底层系统之上进行拼接。
但你得承担理解数据模型的成本（这非常难）、做集成的成本、理清语境是否存在的成本，还要承担决策和建议输出到财务管理、供应链或采购流程中的风险。这些流程必须是“确定性”的，不像前端业务流程（如线索机会等）可以是“概率性”的。在核心业务中，一个简单的错误对组织来说代价极其昂贵。你实际上是在增加组织的“运维冰山”，增加了维护和集成成本，有时这甚至会阻碍智能体层的应用。
总而言之，对我来说，这种应用、数据、智能体体验与底层核心操作系统及任务关键型系统的无缝结合，不仅创造了单纯 PaaS 供应商无法比拟的价值，还带来了更确定的结果。
因为我们为其提供了深厚的流程理解、数据模型、SAP 知识图谱（Knowledge Graph）等。我们将其构建为一种经过后期训练的模型，与现成的模型配合使用。这两者结合所创造的价值，我们认为是无与伦比的。
虽然关于 SaaS 应用的未来争论很激烈，但对我们来说，重点在于即将到来的 Sapphire 大会的成果。事实胜于雄辩。客户反馈给我们的信息是：他们想要运行一个自主化的财务部门、供应链或采购部门。这需要一种连接的可信度，以确保整辆“车”是自主的。而不是在底层系统上买一层软件，指望它能像把 1990 年的老宝马升级新软件一样自动带你回家。你可以尝试，但风险极大。
Adam Wood那样的车，你自己肯定也不想坐进去。
Muhammad Alam没错，没错。
Adam Wood这很有道理。你刚才提到了一点，这也是投资者的一个巨大担忧：并非底层的记录系统（Systems of Record）会被取代，而是用户界面会转向基于聊天的 LLM 接口。更多的交互发生在那里，更多的价值也在那里产生。对于运行多个记录系统的客户，投资者认为这种方式行得通。
你如何看待这个风险？你有多大意愿与那些公司合作实现数据访问？对于系统中已有的智能价值，你是在保护它，还是倾向于合作？
Muhammad Alam这是一个信息量很大的问题，我试着回答，如果遗漏了哪部分请提醒我。首先是你提到的交互层——智能体体验交互层。我们确实相信，技术栈的形态在很长一段时间以来首次发生了变化，因为顶部出现了一个新的层，即覆盖在所有底层之上的智能体体验层。可以说，底层的一切变得更趋向平台化、商品化，价值向上转移。无论是对客户创造的价值，还是能收取溢价的组织，价值都转移到了交互层。
以前我们应用层处于顶部，现在依然是，世界还没完全彻底改变。但我们看到了变化的迹象。所以对我们来说，并不是说底层应用、数据、PaaS 和 IaaS 消失了。它们依然存在。
问题在于，为了让这个新层发挥作用，如何创造最大价值？我们相信，智能体层和应用层必须共存，因为那是数据产生的地方、采取行动的地方、合规和法定要求发生的地方。特别是对于 SAP 所在的这类应用。如果你只是一个单赛道的应用，比如只做人力资源（HCM）或前端应用，那是完全不同的图景。我们在去年的 Sapphire 舞台上说过，我们相信“各领域最佳（Best-of-breeds）”的独立软件在这一新世界中将会举步维艰。
SAP 的护城河即便在这个新层级中依然存在。如果价值上移，应用层就变成了平台。从应用平台的角度看，组织告诉我们，他们需要财务、采购、寻源、供应链、HCM、客户体验（CX）在这个平台层实现端到端的无缝协作。所以 SaaS 实际上成了新的平台。
能够跨越如此广泛的业务流程，提供 SaaS 平台来支撑端到端体验的公司，用一只手就能数过来。如果你在这个平台上挑选 6 个不同的供应商，你得自己做集成，自己理顺数据模型，还得把数据推送到别处去连接。客户对我们这种整合的方式很有共鸣，因为这能让他们消融“冰山”，即降低维护复杂度和 TCO。
话虽如此，作为 SAP 的产品领导者，我很清楚我们必须在智能体层占有一席之地。我们希望当有人使用 Joule（SAP 的 AI 助手）时，他们能在同一个窗口询问财务、供应链或采购的问题，并通过 SAP 知识图谱和微调模型获得最佳答案。这种智能体体验利用了我们的护城河，为我们创造了自主化的体验。这很难作为一个纯粹的 PaaS 故事构建在他人系统之上。
这就是我们正致力于解锁的领域。将核心应用重新定义为智能体体验，是我们极力推进的方向。你也会从产品创新的角度听到更多相关信息。
但在这一过程中，我们并不只想成为“SaaS 即平台”的提供商。我们要参与智能体层的竞争。当然，我们会兼容 A2A（应用对应用），如果你有其他工具想理解 SAP 数据，也可以通过我们的智能体层来实现。这为 SAP 的智能体层创造了粘性，涵盖了组织中发生的其他活动。
虽然我们的系统是任务关键型的，但在 99% 的案例中，我们不是客户环境中唯一的应用。还有一些深度的行业应用，比如石油天然气的上游下游，或者制药行业。当然有些行业我们非常完备，比如离散制造，基本可以全部在 SAP 上运行。但我们的护城河允许这种程度的互操作性。
Adam Wood你多次提到数据和业务语境。这种“语义业务语境（Semantic Business Context）”在今天到底有多重要？我常听到的一个问题是：这些 AI 模型难道不能进入系统并自行推断出这些结构吗？
Muhammad Alam是的，它们可以。我认为它们能做到。但区别在于：针对哪种应用？对于那些熟悉 MCP（模型上下文协议）服务器运作的人来说，你可以在单赛道、单领域的应用前放一个 MCP 服务器，它在将自然语言查询转换为答案方面表现得相当不错。但只要 MCP 服务器下接的工具超过一定数量，准确率就会失控，你无法信任它。
看一看 SAP 的景观：跨财务的 SaaS 平台——即使只看其中一个，其复杂性也是巨大的。数据模型、表、实体、客户构建的扩展，规模如此之大，绝不是在上面放一个简单的 MCP 服务器就能搞定的，尽管你可能在某些 LinkedIn 动态里读到它有多么惊人。
听着，我认为对语境的理解是我们最深的护城河之一。即使作为软件的发布者，要以一种让 SAP 知识图谱、流程图谱和语境图谱能够大规模服务于所有智能体和自然语言交互的方式来解决它，也是非常困难的。我们已经投入了一年半的时间，当时我们说已经非常接近实现 SAP 知识图谱了。既然连我们做起来都这么难，这正是我们的信心来源：要大规模解决 S4、Ariba 和供应链系统的数据语境，是一件极难的事情。这就是护城河。
所以，你有原始数据，但数据之间的关系、之上的语义丰富性以及它们在流程中的使用方式，才构成了护城河。这就是我们正在构建的微调模型，Joule 和智能体都在其上运行，以应对那些极其庞大且难以轻易理解的企业业务面。
现在你可以把原始数据拿出来放到别处。客户现在就在这么做。但从定义上说：第一，你承担了巨大的负担，因为你失去了语义语境；第二，你也失去了权限和授权体系。一旦你把数据放入 Databricks、Snowflake、Azure 或 Google Big Query，它就变成了“扁平数据”，没有了权限和授权，而这至关重要。你总不能因为有了生成式 AI，就开始把工资单数据分享给所有员工，或者大规模共享财务和供应链数据。
我们保留了这些体系。因此我们的合作伙伴关系（特别是与 Databricks 的合作）允许客户在保持“数据引力”的同时，利用我们去年推出的 SAP 业务数据云（Business Data Cloud）中的语义丰富性，从而创造更强大的场景。
Adam Wood所以这关乎“点工具 SaaS 方案”与“具备广度、复杂性、合规与治理的系统”之间的区别，这正是你们与同行的差异所在。
再说回数据，这显然是你们的大护城河。你提到了业务数据云（BDC）。你能聊聊客户如何负责任地利用这些数据，以及你们是如何管理这些合作伙伴关系的吗？
Muhammad Alam好的。我们在不到一年前推出了业务数据云，最初是与 Databricks 合作，随后宣布了与 Snowflake、Azure 和 Google 的合作。作为第一年的产品，它取得了巨大的成功。这并不意外，因为数据是驱动 AI 价值的燃料。
在架构设计上，我们实现了两件事。第一，我们确保为客户提供一流的数据工程工具。目前我们不认为需要在数据工程工具领域进行肉搏式的自主研发，因为那个市场已经非常成熟且趋于商品化。所以我们将这些工具原生嵌入（某些情况下是 OEM）在业务数据云中，在保留数据引力、语义丰富性的同时，让客户利用这些工具创造价值。
我们专注于自己能增值的领域：跨应用的协调数据模型、连接性、知识图谱和语义丰富性。在已经商品化的数据工程领域，我们选择合作伙伴，原因有二：
1. 如果你想通过别人的 AI 工具在这些数据上创造价值，BDC 依然是首选路径。这样我们就处于客户创造价值的流程中。通过我们提供的附加价值，我们获得了粘性和关联度。正如刚才讨论的，这比从数据库提取原始数据再自行拼接要有效得多。
2. 因为数据以这种方式可用，我们可以利用之前提到的 AI 平台，在 BDC 之上帮助创造智能体体验。由于我们的平台涵盖了大部分核心业务流程，通过在平台上的合作，我们成为了创造交互层和智能体层的主要伙伴。这为客户创造了价值，也为我们和利益相关者带来了溢价。
在这两种情况下，我们都是价值链的一部分。
在去年秋天的 SAP Connect 活动上，我们展示了一些很好的客户案例。我们能做而那些 PaaS 智能体层做不到的独特之处在于：我们可以提供“开箱即用”的智能体，它们在应用、数据、智能体的无缝体验中运行。你可以进行扩展（比如添加前置/后置逻辑），因为每个客户都是独特的。但相比买个 PaaS 平台再自己摸索，这种方式实现价值的速度更快，TCO 更低。
[Image illustrating an "Out-of-the-box Agent" for accounts payable or supply chain, showing it pre-connected to SAP data and processes]
这成为了我们在其他护城河之上的又一价值主张。虽然生成式 AI 仍处于早期阶段，但 CIO 和 CEO 们面临着巨大的董事会压力，要求展示价值。很多组织选择东拼西凑一些东西来交差，但其终身 TCO 是巨大的。我们则通过正确的扩展方案，帮助客户开箱即用地释放智能体价值，从而避免陷入长期的维护负担。
Adam Wood为了确保我理解正确：在离散制造等环境下，SAP 可以端到端运行，客户对业务数据云的需求可能较小；但在与多个记录系统和应用并存的异构环境中，BDC 的价值更大，因为可以引入不同数据集并在此基础上构建？可以这样理解吗？
Muhammad Alam不，不是这样。如果我给了你那样的印象，我得澄清一下。只要你是 SAP 的客户，无论哪种形式，业务数据云都有价值。因为它带来了经过协调、保留了语义、权限和授权、并带有 SAP 知识图谱的数据，你可以据此构建或直接使用我们提供的开箱即用智能体层。
区别在于，像离散制造这种行业，大部分数据本身就来自 SAP。而在石油天然气行业，SAP 数据在，你也可以通过“零拷贝（Zero-copy）”方式无缝共享非 SAP 数据。BDC 允许我们在所有客户中充当那个数据层和“应用-数据-智能体”层。对于外部数据较多的情况，我们可以通过合作伙伴关系实现零拷贝共享，将数据聚合在一起。
Adam Wood明白了。
Muhammad Alam它在两种流程中都有效。
Adam Wood好的。我们昨天听到了一个业务数据云合作伙伴的发言，他们谈到从分析型（OLAP）世界开始，加入交易型（OLTP）功能，进入交易领域，并谈论应用层。我的问题是，从 SAP 的角度来看，你如何保持对这个环境的控制？因为我猜这些合作伙伴可能也有野心去构建应用和智能体。SAP 如何管理这种既是合作又是潜在竞争的关系？
Muhammad Alam是的。顺便说一下，我发现那位合作伙伴没穿西装，我也该学学他，不该穿得这么正式（笑）。
对我来说，关键在于看合作的本质。以 Databricks 为例，我们在 BDC 内部集成了 Databricks。这让我们在确保数据引力留在 SAP 框架内的前提下，利用他们的数据工程工具来构建智能体平台。如果你有其他数据，可以零拷贝共享并构建。Snowflake 也是如此。
我们的合作允许在 BDC 内部利用他们平台的优势。但如果客户已经把海量数据放在外面，你可以把 BDC 里的 SAP 数据零拷贝共享过去，这依然让我们留在价值流中。
回到之前的问题。我们认为，那种“因为数据在那儿，所以有人会在我们的应用领域内开始构建应用”的情况，在现实的客户环境中不太可能发生。
他们能在那些数据平台上构建自定义应用吗？可以。但我们谈到了“开箱即用”的价值，因为我们有深厚的语境图谱、我们采用的模型、以及上周在 TechEd 上推出的 Rapid 系列（允许在交易流中进行数据科学处理）。这里有足够的价值主张让客户觉得：“在 BDC 和我们的智能体平台上为我们熟悉的领域构建东西，价值最高。”当然，那些平台也可以填补其他的空白。
Adam Wood有道理。你实际上已经给了我们一些关于 BDC 总合同价值（TCV）的数据。我感兴趣的是，这些项目的“价值实现时间（Time to value）”是多久？从签约到上线并产生收益需要多快？
Muhammad Alam我想 Alexandra（SAP 投资者关系负责人）可以在线下提供具体数字。但目前超过一半的 BDC 客户已经投入使用。BDC 的价值实现速度非常快。它不像典型的 ERP 实施那样需要耗费多个月才能看到价值。
这主要是因为我们的产品构建方式：如果你有 SAP 环境，我们构建的数据产品就开始向 BDC 输送数据，所有工具都可供你创造价值。我们还可以帮助你完成 BW（业务仓库）的现代化改造。基于这两个价值主张，我们看到了非常健康的 BDC 使用量和极短的上线时间。
Adam Wood很有参考价值。最后聊聊这个：软件公司有时被简化为“生成代码的能力”。如果生成代码变得更便宜、更快，价值似乎就消失了。但在我看来，软件公司的内涵远不止生成代码。你能谈谈如何看待生产代码成本的降低，以及未来客户愿意为此支付什么？随着行业从按席位计费转向按消费计费，这种结构会如何变化？
Muhammad Alam是的，这是我们投入大量时间思考的领域，即我们需要做出哪些演变。看我们目前的模式，我们有多种并行的模式。对于基于 Joule 的功能，相当一部分价值是直接嵌入应用中的——如果你运行 SAP 应用，就可以交互并获益。
此外，我们还有更高端的“每用户每月”计费模式，这为客户提供了可预测性：在该类别下我们发布的任何功能，你都可以尝试使用，而不用觉得每加一个功能都要精算成本。
现实情况是，从广义上讲，这些东西的投资回报率（ROI）在大规模应用中仍有待验证。所以我们不想陷入这种争论：“要开启这个功能，需要消耗多少额度，所以你得证明它的价值。”我们更倾向于说：“这是一套持续优化的能力，你可以根据需要尽情使用。”当然，对于深度消耗资源（Consumptive）的场景，我们之上也有基于消耗的计量方式。
我们还在研究基于“产出（Outcome）”的衡量标准。即使是现在，我们也有基于使用量的指标。甚至我们的“每用户每月”本质上也是基于使用的。在核心应用如 Ariba 中，我们谈论的是流经系统的支出额度（Spend），而不是使用应用的具体人数。如你所料，我们会持续观察行业走向，并根据客户反馈进行演进。
Adam Wood但目标是在收费前先证明价值……
Muhammad Alam显然。在 AI 方面，SAP 认为我们有责任通过运行这些任务关键型应用来证明和展示价值。我们有能力让价值先行显现，然后通过反馈和讨论，确定长期的商业模式。
Adam Wood太棒了。我们还有很多可以讨论的，但时间快到了。再次感谢你的参加。