为什么世界仍在运行 SAP

作者：Eric Zhou & Seema Amble A16Z | 来源：SandHill.io

借助 AI，初创公司及其客户已将注意力集中在全新的功能及由此衍生的产品上。想想那些闪亮的新语音代理、工作流自动化工具和文本到应用平台。

虽然这些领域已经并将继续涌现许多激动人心的企业（我们已投资其中几家！），但 AI 将在一些远不那么光鲜亮丽却价值连城的事情上产生巨大影响：帮助企业从其已经运行的大量软件中获得更多价值。在此，我们不妨提出一个听起来近乎冒犯的问题，直到你在一家财富 500 强公司待上一周后才会明白：为什么人们还在使用 SAP（以及 ServiceNow 和 Salesforce）？

简而言之，SAP 或任何大型的传统记录系统，都捕获了使用它的企业中的关键数据。但更重要的是，企业已经对其进行了定制，并在其之上建立了一套特定的流程和角色，而其中大部分内容实际上并未在任何地方被记录下来。迁移系统的过程一直很痛苦、昂贵且耗时——通常需要一支庞大的顾问团队、数年时间以及数亿美元的资金。从 SAP ECC 升级到 SAP S4HANA 可能耗资 7 亿美元，耗时 3 年，并需要一支来自埃森哲的 50 人团队。而且在迁移之后，该软件几乎只能用于生成无法操作的只读报告。

直到现在，情况才有所改变。AI 释放了升级、定制、替换以及更坦率地说，更好地访问和使用这些记录系统中捕获的数据的机会。

最终，AI 的目标可能不是“取代 SAP/ServiceNow/Salesforce”，而是让它们变得更具可编程性和更易于使用。赢家将是那些（1）利用可衡量的风险和时间缩减来接入转型预算，然后（2）作为可信赖的工作控制平面扩展到日常运营中，逐步将传统 UI 分解为可组合、受治理、AI 辅助的行动和轻量级应用的平台。换句话说，记录系统将继续存在；而接口、自动化和扩展层将成为新的软件前沿。

SAP 令人痛苦，但我们仍在使用它

为了更好地说明这一点，让我们先简单介绍一下 SAP 及其功能。从表面上看，这些系统难以驾驭，修改起来很痛苦，但不知何故，它们仍然是全球最大型组织运营的支柱。想象一下使用 SAP 是什么样子！

但那个“不知何故”正是机会所在。

那个令人不安的答案是，在丑陋的 UI 和无尽的配置之下，这些系统非常强大：它们编码了企业的规范数据模型、保持合规性的权限和控制、使其能够大规模运营的工作流，以及连接数十（或数百）个下游流程的集成。它们不是消费者意义上的“应用”，而是以表格、角色、审批、过账逻辑和异常处理形式表现出来的累积的机构记忆。

替换这一切不仅仅是昂贵；它还充满风险。一家公司投入得越多——自定义字段、工作流、定价规则、报告逻辑——这个系统就越成为转换成本的护城河和竞争优势。这也是为什么可扩展性如此强大的原因：每个企业都是独一无二的，变化是永恒的（新法规、新产品、新组织结构），而这些平台之所以能够生存，是因为它们可以被改造以适应现实。挑战在于，正是这种使它们变得有价值的可扩展性也使它们变得脆弱：每一次定制都成为未来升级的隐患，每一个工作流都成为一个迷宫，每一个屏幕都成为每个必须使用它的人的负担。

这种脆弱性无处不在。尽管 CRM 得到广泛采用，但用户满意度仍然参差不齐，而 ERP 中的大量定制则一直与项目超期和预算超支联系在一起。员工们正淹没在碎片化的工作流中——数字化员工每天在不同应用程序之间切换约 1200 次（每周大约损失 4 小时），47% 的数字化员工难以找到完成工作所需的信息。大规模的“转型”项目常常受挫；据估计，大约 70% 的项目未能实现目标。与这种摩擦相关的支出是巨大的：仅软件实施/系统集成市场在 2023 年就达到了约 3800 亿美元。

这里的流程和痛点为 AI 改变这些软件的实施和使用方式提供了机会。理解这个机会最简单的方法是遵循套件的生命周期：首先你实施或迁移它，然后你每天都生活在其中，然后随着业务的变化在其之上进行构建。在每个阶段，工作都是将混乱的人类意图转化为针对记录系统的正确、可审计的行动。

让我们看看 AI 如何在每个阶段改进我们使用传统软件系统的方式。

实施

让我们从实施开始——这是风险最高、预算最敏感的阶段，也是回报最明确的阶段。具体来说，这看起来像是将混乱的发现（会议、文档、工单）转化为结构化的需求，然后自动生成实施工作流：流程和字段映射、配置和代码、测试脚本、切换计划和迁移手册——以及上线所需的数据清理和验证。要做好这一点非常困难：德国超市巨头 Lidl 曾在一个著名的案例中，在花费了 5 亿美元后放弃了向 SAP 过渡的努力。

这里的公司构建了 copilot、项目管理工具和其他软件来帮助迁移和实施。以下是一些在该领域工作的初创公司的例子（Andreessen Horowitz 投资了其中一些公司）：

• Axiamatic 是 ERP 的 AI“保障”层：它从项目工件中构建知识图谱，并通过 Slack/Teams 标记需求/变更管理中隐藏的故障，以降低 S/4HANA 项目的风险并加速其进程（与 SAP Build 合作；并融入毕马威/安永/IBM 的工作流程中）。
• Conduct 是一个代码和流程映射的 copilot，它在 ECC→S/4 之间生成语义层和技术文档，并通过对自定义表/API 的问答来加速内部接管。
• Auctor 为系统集成商/专业服务提供代理式实施交付，将发现过程自动捕获为结构化需求，然后成为工作说明书（SOW）、设计文档、用户故事、配置和测试计划的记录系统。
• Supersonik 帮助渠道/MSP 和客户进行 AI 驱动的产品赋能——在真实 UI 内部进行教学的视觉和语音代理，减少了对解决方案工程师（SE）的人员需求，并实现了由经销商主导的实施/扩展。
• Tessera 的 AI 原生系统集成商端到端地管理企业转型——连接到客户现有的 ERP 实例，评估其实施方式，然后在迁移过程中标记/自动修复需要更改的内容。

这些公司通过使转型更快、更便宜、风险更低来创造价值。它们通过几种关键方式做到这一点：在需求和变更管理中及早发现问题，防止其滚雪球式地恶化；压缩时间表（一个月的延误就可能造成数百万美元的损失）；将混乱的项目数据转化为结构化知识，以便内部团队能够更快地接管；以及通过自动化映射、文档、测试和赋能来减少对大型系统集成商团队的依赖。

我们看到，有更多初创公司可以构建与现有合作伙伴合作而非对抗的工具。具体来说：

• 共享成果和风险的实施代理（想想需求跟踪、配置比较、切换模拟、代码生成和漂移检测）
• 保持知识最新且易于访问的语义文档工具
• 将培训和渠道推广转变为可重复产品的赋能代理

因为初创公司可以减轻企业级的负担，它们可以根据避免的延迟来定价，并销售给首席信息官和首席财务官已经在花费的转型预算，从而在此过程中取代臃肿的系统集成商项目。

使用与维护

接下来，在软件套件实施之后，使用它意味着要应对这些软件套件如今混乱的 UI。日常工作跨越数十个屏幕，角色更替会重置专业知识，而大量的边缘案例工作流永远得不到一流的产品待遇。用户花费时间寻找字段，在系统之间镜像数据，并要求运营团队“运行这份报告”。结果是周期时间缓慢、可避免的错误以及持续的培训负担。

机会在于 AI 可以用一个更友好、功能更强大的“行动系统”来包装传统系统。

这个领域的公司构建的工具可以帮助团队从他们已经使用的系统中获得更多价值。在实践中，这看起来像一个存在于 Slack 中或作为浏览器侧边栏的 copilot，它可以使用语义搜索回答“我在哪里可以找到 X？”或“我该如何做 Y？”，然后在有 API 的情况下采取安全的操作（创建案例、过账日记账分录、更新供应商条款）。这些工具还可以将多个应用的工序链接在一起（“从 SAP 中提取上一季度的采购订单，在 Coupa 中检查合同条款，在 ServiceNow 中起草一份差异说明”），并带有人机审批步骤、审计跟踪和精细的基于角色的访问控制（RBAC）。最好的工具会跟踪采用率、节省的时间和错误率。

在企业中，许多重要的工作仍然没有通过 API 清晰地暴露出来——它们存在于屏幕、胖客户端、虚拟桌面基础架构（VDI）会话和半文档化的管理控制台中。这就是为什么现代的“计算机使用”代理是 API 优先的 copilot 的一个如此重要的补充：它们将自动化的可及范围扩展到了最后 30-40% 的工作流，在这些工作流中根本没有可靠的端点可以调用。核心能力不是“点击按钮”，而是在混乱环境下的可靠性——能够感知 UI、锚定到稳定元素、从弹出窗口和布局漂移中恢复，并设置检查点以便能够安全地在流程中恢复的代理。当与验证（差异比较、对账、沙盒运行）和企业控制（单点登录、机密信息、最小权限、审计）相结合时，这将过去的手动工作转变为受治理、可重复的自动化——工单分类、期末结账步骤、客户更新、定价变更——即使在 SAP/ServiceNow/Salesforce 中那些供应商从未为自动化构建的部分也是如此。API 使正常路径变得快速，而计算机使用则使长尾工作流变得可自动化。

像 Factor Labs 和 Sola 这样的公司已经在生产中部署这些代理，取代了业务流程外包（BPO）的支出，并帮助大型组织大规模地自动化任务。

扩展

最后，即使你让 SAP/ServiceNow/Salesforce 更易于使用，你的业务仍会不断变化，这意味着你的记录系统也必须随之变化。新产品、新政策、新收购、新法规，以及大量永远无法证明一个核心模块项目合理性的长尾工作流，意味着需要不断地工作以保持软件与业务的实际状态相关。从历史上看，团队有两种选择：定制套件（并继承脆弱性税）或构建一次性应用（并在集成、治理和维护方面苦苦挣扎）。这是 AI 的第三个切入点：在记录系统之上快速交付小型的、受治理的体验，同时保持核心的整洁。

在传统资产之上构建全新的工具和自动化，成为不受欢迎软件之上的“可爱”层。这种模式始于一个统一的数据和行动平面：通过 API 和事件（以及在需要时通过安全的 UI 捕获）从记录系统中读取数据，将其规范化为业务对象的语义模型（订单、供应商、案例），然后暴露一组受治理的、带有 RBAC、审批和审计的操作。

在这个平面之上，团队可以交付感觉现代且为特定目的而构建的专注体验。你不再需要让采购分析师通过 12 个 SAP 事务来完成供应商的入驻，而是给他们一个单一的“供应商入驻”轻应用，该应用可以收集文件、检查重复项、路由审批，并将正确的记录过账回 SAP。你不再需要让收入运营团队打开五个 Salesforce 屏幕来更新续订条款，而是给他们一个电子表格速度的编辑器，可以批量编辑、根据政策进行验证、预览影响，然后以完整的审计跟踪提交更改。你不再需要又一个“门户项目”，而是给一线团队一个命令面板，可以回答问题并执行他们每天做的少数操作（“创建退货”、“延长信用”、“开启一个二级严重性问题”、“过账应计费用”），跨越多个系统，而无需在 20 个标签页中费力地寻找。

这些扩展还解锁了跨系统的工作流和自动化，这是任何单一供应商都不会优先考虑的：事件驱动的触发器，如“如果发票已过账且差异 >3% → 起草一份解释 → 路由以供审批”，或“如果工单被重新打开两次 → 创建问题记录 → 分配负责人 → 更新客户”，并在重要的地方设置人机交互的检查点。随着时间的推移，最有价值的部署会变成可重用的“意图包”——从报价到收款、供应商入驻、期末结账——它们不仅编码了要做什么，还编码了如何在你的环境中安全地做。

像 General Magic 的 Cell 这样的平台，使得构建这些定制工作流的基石变得具体化：你上传 OpenAPI 规范，使每个端点都成为一个操作，然后用一个单一的脚本标签嵌入一个本地命令栏，该命令栏执行真实的 API 调用，并由分析、多租户、安全护栏和 RBAC 支持，因此工作从重建另一个 UI 转移到在你已经信任的系统之上组合正确的操作和策略。

终局会是什么样子？

我们认为，传统系统大多会继续存在，但它们将不再是工作发生的表层。ERP、CRM 和 ITSM 套件的嵌入程度太深，无法在典型的软件更迭周期中被替换掉；它们演进缓慢，并仍然是记录系统。将会改变的是位于其上的面向用户的“行动系统”：AI 将成为发现系统如何工作、在其上执行工作流以及交付绕过传统 UI 的小型、现代化体验的默认界面。换句话说，桥梁变成了高速公路。

这个领域中经久不衰的软件将看起来不像一个聊天机器人，而更像一个操作层：一个统一的数据和行动平面，带有一个业务对象的语义模型，外加使 AI 在生产中值得信赖的护栏。如果你是最终用户，你不再需要学习使用哪个屏幕、字段和事务代码（然后在每次 UI 或流程改变时重新学习），而是描述你想要的结果。

护城河通过实际使用而不断加深：每一个成功的工作流都成为一个可重用的意图，每一个异常都成为一个护栏，每一个迁移工件都成为活的血缘关系，每一次集成都加深了企业实际运行方式的图谱。随着时间的推移，“AI 层”成为团队去理解变更影响、防止漂移、衡量投资回报率和交付新工作流的地方，即使底层系统保持不变。