Created time
Mar 30, 2026 06:32 AM
category
library
date
Mar 30, 2026
status
Published
icon
password
slug
why-people-still-use-sap-a16z
summary
本文探讨了AI如何帮助企业在使用传统软件（如SAP）时提升效率和可用性，尽管这些系统存在复杂性和高昂的迁移成本。
tags
AI+商业
A16z
type
post
以下为 AI 翻译。
随着 AI 的出现，创业公司和客户的目光纷纷投向全新的功能和产品——炫目的语音代理、工作流自动化工具、文字转应用平台，不一而足。
这些领域确实正在涌现（并将继续涌现）许多令人兴奋的企业，我们也投资了其中一些。但 AI 将对一些没那么光鲜、却更有价值的事情产生深远影响：帮助组织从已有的海量软件中获得更多价值。
如果你在财富 500 强公司待上一周，很可能会问出这样一个听起来有点不礼貌的问题：为什么人们还在用 SAP（以及 ServiceNow 和 Salesforce）？
简短的回答是：SAP 或任何主要的传统记录系统（System of Record），都承载着业务中最核心的数据。在此之上，企业还积累了大量定制化配置——特定的流程、角色分工，其中大部分甚至没有任何文档记录。迁移这些系统极其痛苦、代价高昂、耗时漫长——通常需要庞大的顾问团队、数年时间和数亿美元的预算。
从 SAP ECC 升级到 SAP S/4HANA，可能耗资 7 亿美元、历时 3 年，还需要埃森哲派出 50 人的专项团队。而迁移完成后，这些软件往往也只能用于生成无法操作的只读报告。
这种局面直到现在才出现转机。AI 开启了升级、定制乃至替换这些系统的机会——更根本的是，它能让组织更好地访问和使用记录系统中的数据。
最终，AI 的目标可能并非"取代 SAP / ServiceNow / Salesforce"，而是让它们更具可编程性、更易于使用。赢家将是那些能做到两件事的平台：
- 切入转型预算，并能显著降低风险、缩短时间线；
- 作为受信任的工作控制平面，扩展到日常运营中，逐渐将传统 UI 拆解为可组合、受控的 AI 辅助操作和轻量化应用。
换句话说，记录系统依然存在，但界面层、自动化层和扩展层将成为新的软件前沿。
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：为系统集成商（SI）/ 专业服务提供代理式实施交付，将调研内容自动捕获为结构化需求后，成为工作说明书（SOW）、设计文档、用户故事、配置和测试计划的记录系统。
- Supersonik：通过 AI 驱动的产品赋能，在真实 UI 中以视觉和语音代理的形式进行教学，帮助渠道 / MSP 和客户减少对销售工程师的依赖，并支持渠道主导的实施和扩展。
- Tessera：AI 原生系统集成商，负责端到端企业转型——连接客户现有 ERP 实例、评估实施现状，并在迁移过程中自动标记并修复需要变更的内容。
这些公司通过让转型更快、更便宜、风险更低来创造价值，核心路径包括：
- 在需求和变更管理阶段及早发现问题，防止雪球效应；
- 压缩时间线（延迟一个月可能损失数百万美元）；
- 将混乱的项目数据转化为结构化知识，帮助内部团队更快接管；
- 通过自动化映射、文档、测试和赋能，减少对大型 SI 团队的依赖。
我们认为，初创公司还有更大的空间——构建与现有合作伙伴协作而非竞争的工具，例如：
- 实施代理：分担成果与风险（需求跟踪、配置对比、切换模拟、代码生成、偏差检测）；
- 语义文档工具：保持知识库实时更新且易于访问；
- 赋能代理：将培训和渠道推广转化为可重复的产品化流程。
由于初创公司可以减轻企业级项目的实施负担，他们可以按避免的延迟成本定价，切入 CIO 和 CFO 已经在花钱的转型预算，同时逐步取代臃肿的 SI 服务支出。
使用与维护阶段
软件套件部署上线之后，日常使用同样充满摩擦：界面繁杂，工作跨越数十个操作界面；人员流动导致技能流失；大量边缘工作流从未得到一流的产品化支持。用户花时间寻找字段、在系统间同步数据，或不断请求运营团队"跑一下这个报表"。结果是流程周期拉长、可避免的错误频发、培训负担居高不下。
这里的机会在于：用 AI 为传统系统包裹一层更友好、更强大的"行动系统"（System of Action）。
实践中，这看起来像是一个运行在 Slack 中或作为浏览器侧边栏的 Copilot，它可以：
- 用语义搜索回答"我在哪里能找到 X？"或"我该怎么操作 Y？"；
- 在有 API 的情况下执行安全操作（创建案例、发布日记账分录、更新供应商条款）；
- 串联多应用工作流（"从 SAP 提取上季度采购订单，在 Coupa 中检查合同条款，在 ServiceNow 中起草差异说明"）；
- 带有个人审批步骤、审计追踪和细粒度的权限控制（RBAC）。
最好的工具还会持续追踪采用率、节省的时间和错误率。
然而，企业中很多重要工作并没有通过 API 清晰暴露——它们藏在屏幕、厚客户端、VDI 会话和文档残缺的管理控制台里。这正是现代"计算机使用"代理（Computer-use agents）成为 API 优先 Copilot 重要补充的原因：它们将自动化覆盖范围扩展到了最后 30–40% 的工作流——这些工作流根本没有可靠的调用端点。
这类代理的核心能力不是"点击按钮"，而是在混乱中保持可靠性：感知 UI、锚定稳定元素、从弹窗和布局偏移中恢复，并记录进度以便安全地中途恢复。配合验证（差异对比、对账、沙盒运行）和企业控制（SSO、密钥、最小权限、审计），这将曾经的手动工作转化为受控、可重复的自动化——工单分拣、结账步骤、客户更新、价格变更——即便是在供应商从未为自动化设计的 SAP / ServiceNow / Salesforce 模块中也同样适用。
API 让常规路径变快，计算机使用让长尾路径可自动化。
Factor Labs 和 Sola 等公司已在生产环境中部署了这类代理，替代了业务流程外包（BPO）支出，帮助大型组织实现大规模任务自动化。
扩展阶段
即便让 SAP / ServiceNow / Salesforce 变得更易用，业务本身仍在不断变化——新产品、新政策、新收购、新法规，加上大量永远无法单独立项的长尾工作流，都要求软件持续演进以匹配业务现实。
历史上，团队面临两难：定制套件（承担脆弱性代价），或构建一次性应用（难以集成、治理和维护）。
AI 提供了第三条路：在记录系统之上快速发布小型、受控的体验，同时保持核心系统的整洁。
这种模式始于一个统一的数据与行动平面：通过 API 和事件（以及必要的安全 UI 捕获）从记录系统中读取数据，归一化为业务对象的语义模型（订单、供应商、案例），再暴露一套带有权限控制、审批和审计的受控操作集。
在这个平面之上，团队可以发布感觉现代、专门设计的聚焦体验：
- 与其让采购分析师通过 12 个 SAP 交易来完成供应商入驻，不如给他们一个单一的"供应商入驻"轻量应用——收集文档、检查重复、路由审批，并将正确的记录传回 SAP；
- 与其要求 RevOps 打开五个 Salesforce 界面来更新续约条款，不如给他们一个具备电子表格速度的编辑器——批量编辑、按策略验证、预览影响，再提交带有完整审计追踪的变更；
- 与其再搞一个"门户项目"，不如给一线团队一个命令面板——可以回答问题，并跨多个系统执行他们每天做的少数操作（"创建退货"、"延长信用"、"开启 2 级严重事故"、"发布应计项目"），而无需在 20 个标签页中翻找。
这些扩展还开启了任何单一供应商都不会优先考虑的跨系统工作流与自动化，例如：
- 由事件驱动的触发器："如果发票已发布且差异 >3% → 起草说明 → 路由审批"；
- "如果工单被重新打开两次 → 创建问题记录 → 分配负责人 → 更新客户"；
- 并在关键环节保留人工干预节点。
随着时间推移，最有价值的部署会演化为可复用的"意图包"（Intent Packs）——从报价到现金、供应商入驻、期末结账——不仅编码了"做什么"，也编码了"如何在你的环境中安全地去做"。
General Magic 的 Cell 等平台已让构建这些定制工作流的组件触手可及：上传 OpenAPI 规范，将每个端点变成一个可调用操作，通过单个 script 标签嵌入原生命令栏，并附以分析、多租户、安全护栏和权限控制。工作重心由此从"重建另一个 UI"转向了在已信任的系统之上组合正确的操作与策略。
最终，结局会是什么样？
我们认为，传统系统大多会持续存在，但它们将不再是工作真正发生的地方。
ERP、CRM 和 ITSM 套件嵌入太深，无法按照典型的软件更替节奏被彻底拔除；它们演进缓慢，并将继续保持记录系统的地位。将要改变的，是坐在其上的面向用户的"行动系统"：AI 将成为发现系统如何运行、跨系统执行工作流，以及发布绕过传统 UI 的小型现代体验的默认界面。
换句话说，桥梁变成了高速公路。
这一类别中真正持久的软件，看起来不会像聊天机器人，而更像是一个操作层：一个带有业务对象语义模型的统一数据与行动平面，加上使 AI 在生产中值得信赖的护栏体系。
对终端用户而言，你不再需要学习该用哪个界面、哪个字段、哪个交易代码（也不需要在每次 UI 或流程变动时重新学习）——你只需描述你想要的结果，系统就会带你到达那里。你会回答几个澄清性问题，看到将要执行的操作预览，然后工具带着正确的审批和审计追踪去完成执行。
闭环操作将变得如此自然：
- "创建退货并通知客户"
- "开启 2 级严重事故并提取最后三个相关事件"
- "入驻此供应商、收集文档、路由审批并设置付款条件"
而这些在今天，需要在 SAP、Salesforce、ServiceNow 和若干张电子表格之间反复跳转才能完成。
最终带来的是：更少的错误与冲销、更少对部落知识的依赖、更快的流程周期、显著降低的培训负担——因为界面默认就是由意图驱动、角色感知且支持自助服务的。
护栏从实际使用中不断积累：每一个成功的工作流变成一个可复用的意图，每一个异常变成一个护栏，每一次迁移产出变成活生生的脉络，每一次集成加深了企业实际运作方式的图谱。随着时间推移，"AI 层"将成为团队理解变更影响、防止偏差、衡量 ROI 并发布新工作流的核心场所——即便底层系统纹丝未动。