a16z：“又贵又难用”的企业软件，才是 AI 的真正金矿

作者：Eric + Seema Amble

编译：深潮 TechFlow

深潮导读：从 SAP ECC 升级到 S4HANA 要花 7 亿美元、耗时 3 年、还得从 Accenture 借调 50 人——然而全球最大的企业仍然在用它。a16z 这篇文章从投资视角拆解了一个反直觉的判断：未来的赢家不是那些"替换 SAP"的公司，而是那些让 SAP 变得可编程、更易用的公司。这个框架对理解企业 AI 赛道的真实机会点极有参考价值。

全文如下：

AI 领域的创业公司和他们的客户，把注意力集中在了全新能力和由此催生的产品上：漂亮的语音 Agent、工作流自动化工具、文本生成应用平台。

这些赛道已经有很多令人兴奋的公司，未来还会更多（我们也投了几家！) . 但 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 合作；已嵌入 KPMG/EY/IBM 的工作流程）。

Conduct 是代码和流程映射的 Copilot，为 ECC→S/4 迁移生成语义层和技术文档，并支持对自定义表/API 进行问答，以加速内部团队接管。

Auctor 为系统集成商/专业服务提供 Agent 驱动的实施交付，自动将需求发现转化为结构化需求，并成为工作说明书（SOW）、设计文档、用户故事、配置和测试计划的记录系统。

Supersonik 为渠道商/MSP 和客户提供 AI 赋能的产品使能——视觉和语音 Agent 在真实 UI 内进行培训，减少售前工程师需求，支持渠道商主导的实施和扩展。

Tessera 的 AI 原生系统集成商端到端管理企业转型——连入客户现有 ERP 实例，评估其实施状况，然后在迁移过程中标记并自动修复需要变更的内容。

这些公司通过让转型更快、更便宜、更低风险来创造价值。具体体现在几个方面：在需求和变更管理阶段早期发现问题，避免滚雪球式扩大；压缩项目时间线（一个月的延误可能耗费数百万）；将混乱的项目数据转化为结构化知识，使内部团队能更快地接管；并通过自动化映射、文档、测试和使能培训，减少对大型系统集成商团队的依赖。

我们认为还有更多创业公司的空间，去构建与现有合作伙伴协作而非对抗的工具。具体来说：

与结果和风险共担的实施 Agent（涵盖需求追踪、配置对比、切换模拟、代码生成和漂移检测）

保持知识实时更新和可访问的语义文档工具

将培训和渠道推广转变为可复用产品的使能 Agent

因为创业公司能够减轻企业级负担，它们可以按"规避延误的价值"来定价，并切入 CIO 和 CFO 已经在投入的转型预算，顺带取代臃肿的系统集成商合同。

使用与维护阶段

软件套件实施完成后，日常使用意味着在这些软件今天那混乱的 UI 中穿行。日常工作横跨数十个界面，人员流动不断清零已有的操作知识，大量边缘案例工作流永远得不到核心产品层面的一等公民待遇。用户花大量时间寻找字段、在系统间镜像数据、找运营团队"帮我跑一下这个报告"。结果是周期时长慢、可避免的错误频发、持续不断的培训负担。

AI 的机会在于，用一个更友好、能力更强的"行动系统"将遗留系统包裹起来。

这个类别的公司构建工具，帮助团队从他们已经在用的系统中获取更多价值。在实践中，这看起来像是一个活在 Slack 或以浏览器侧边栏形式存在的 Copilot——它能用语义搜索回答"X 在哪里？"或"怎么做 Y？"，并在 API 可用时执行安全操作（创建工单、过账分录、更新供应商条款）。这些工具还可以串联起跨应用的复合工作流（"从 SAP 拉取上季度采购单、在 Coupa 查合同条款、在 ServiceNow 起草差异说明"），并附带人工审批步骤、审计追踪和细粒度权限控制。最好的工具还会追踪采用率、节省的时间和错误率。

在企业中，很多重要工作并没有通过 API 干净地暴露出来——它存在于界面、厚客户端、VDI 会话和半文档化的管理控制台之中。这就是为什么现代"计算机使用"Agent 是 API 优先 Copilot 的重要补充：它们将自动化的可触达范围扩展到没有可靠调用端点的最后那 30%～40%的工作流。

核心能力不在于"点击按钮"，而在于在混乱中保持可靠——能够感知 UI、锚定稳定元素、从弹窗和布局漂移中恢复，并设置检查点以便在流程中途安全恢复。

当与验证（差异对比、核对、沙盒运行）和企业管控（SSO、密钥管理、最小权限、审计）结合时，这就把过去需要手动完成的工作——工单分类、期末关账步骤、客户更新、定价变更——转变为受治理的、可复用的自动化，即便是在 SAP/ServiceNow/Salesforce 中那些供应商从未为自动化而构建的部分也能实现。API 让通顺路径变得快速，计算机使用让长尾工作流变得可自动化。

Factor Labs 和 Sola 等公司已经在生产环境中部署了这类 Agent，替换了 BPO 支出，帮助大型组织实现规模化的任务自动化。

最后，即便你让 SAP/ServiceNow/Salesforce 变得更易用，业务仍会持续变化，这意味着记录系统也必须随之演进。新产品、新政策、新并购、新法规，以及永远不足以撑起一个核心模块项目的长尾工作流，意味着需要持续不断地让软件跟上业务的真实状态。

历史上，团队只有两种选择：定制化这套软件（并继承脆弱性的代价），或者构建一次性应用（并在集成、治理和维护上挣扎）。这就是 AI 的第三个切入点：在记录系统之上快速交付小型的、受治理的体验，同时保持核心系统的整洁。

在遗留系统之上构建全新工具和自动化，成为那些"不受人待见的软件"之上的"Lovable 层"。这一模式从统一的数据与行动平面开始：通过 API 和事件（在必要时辅以安全的 UI 抓取）从记录系统读取数据，规范化为业务对象（订单、供应商、工单）的语义模型，然后暴露一套带有权限控制、审批流和审计的受治理操作集合。

在这个平面之上，团队交付感觉现代且专为特定场景设计的体验。与其让采购分析师在 SAP 里走 12 个事务码才能完成供应商入驻，不如给他们一个单一的"供应商入驻"轻量应用——收集文件、查重、流转审批、将正确的记录回写到 SAP。

与其要求 RevOps 打开五个 Salesforce 界面来更新续约条款，不如给他们一个电子表格速度的编辑器，支持批量编辑、政策校验、影响预览，然后以完整审计追踪提交变更。与其再上一个"门户项目"，不如给一线团队一个命令面板，能够回答问题并跨多个系统执行他们每天要做的那几个操作（"创建退货"、"延长信用额度"、"开一个 P2 故障单"、"过应计"），无需在 20 个标签页间翻找。

这些扩展还能解锁跨系统的工作流和自动化——那些没有任何单一供应商会去优先构建的：事件驱动的触发器，比如"如果发票已过账且差异>3%→起草说明→路由审批"，或者"如果工单被二次重开→创建问题记录→分配负责人→更新客户"，并在关键节点设置人工介入检查点。

随着时间推移，最有价值的部署会演变为可复用的"意图包"——报价到收款、供应商入驻、期末关账——不只编码要做什么，还编码如何在你的环境中安全地做到。

General Magic 的 Cell 等平台让构建这些定制工作流的基础模块变得触手可及：你上传 OpenAPI 规范，每个端点就成为一个可调用的操作，然后用一行脚本嵌入一个原生命令栏，这个命令栏可以执行真实的 API 调用，并配有分析、多租户、安全护栏和权限控制——工作的重心因此从"又重建一个 UI"转变为"在你已经信任的系统之上组合正确的操作和策略"。

终局是什么样的？

我们认为，遗留系统大概率会继续存在，但它们将不再是工作发生的界面。ERP、CRM 和 ITSM 套件的嵌入程度太深，无法按照普通软件的节奏被彻底替换；它们演进缓慢，仍将是记录系统。将要改变的是叠加其上的面向用户的"行动系统"：AI 将成为发现系统如何运作、跨系统执行工作流、以及交付绕过遗留 UI 的小型现代化体验的默认界面。换句话说，桥梁将成为高速公路。

这个类别中持续存在的软件，看起来将不像一个聊天机器人，而更像一个操作系统层：一个带有业务对象语义模型的统一数据与行动平面，加上让 AI 在生产环境中值得信赖的护栏。如果你是终端用户，不再需要学会用哪个界面、哪个字段、哪个事务码（也不需要每次 UI 或流程变化后重新学习），而是描述你想要的结果，系统带你到达那里。

系统会问几个澄清性问题，给你看一下它将要做什么的预览，然后以正确的审批和审计追踪完成执行。最终的闭环看起来像是："创建退货并通知客户"、"开一个 P2 故障单并拉取最近三个相关事件"，或者"入驻这个供应商，收集文件，路由审批，设置付款条款"——而这些操作在今天需要在 SAP、Salesforce、ServiceNow 和电子表格之间来回跳转。这带来更少的错误和返工、更少对"部落知识"的依赖、更快的周期时长，以及大幅降低的培训负担——因为界面是意图驱动、角色感知的，并且默认支持自助使用。

护城河在真实使用中不断累积：每一个成功的工作流都成为可复用的意图，每一个异常都成为护栏，每一个迁移产物都成为活的数据谱系，每一次集成都加深了企业真实运作方式的图谱。随着时间推移，"AI 层"将成为团队理解变更影响、防止漂移、衡量 ROI、交付新工作流的目的地——即便底层系统保持不变。