借助人工智能,初创公司及其客户将注意力集中在全新功能和他们所支持的产品上。想想闪亮的新语音代理、工作流程自动化工具和文本到应用平台。

SAP 很痛苦,但我们仍在使用它

为了奠定基础,让我们分享一些有关 SAP 及其用途的信息。从表面上看,这些系统很难驾驭,改变起来也很痛苦,但仍然是世界上最大的组织运作的支柱。考虑一下使用 SAP 会是什么样子!

为什么世界仍然在 SAP 上运行 来源

但“不知何故”就是机会。

令人不安的答案是,在丑陋的用户界面和无尽的配置之下,这些系统非常强大:它们对业务的规范数据模型、保持其合规性的权限和控制、使其可大规模运行的工作流程以及连接数十个(或数百个)下游流程的集成进行编码。它们不是消费者意义上的“应用程序”,而是累积的机构记忆,以表格、角色、批准、发布逻辑和异常处理的形式表示。

更换它不仅成本高昂,而且成本高昂。这是有风险的。公司投资越多(自定义字段、工作流程、定价规则、报告逻辑),系统就越成为转换成本和竞争优势的护城河。这也是可扩展性如此强大的原因:每个企业都是独一无二的,变化是不断的(新法规、新产品、新组织结构),而这些平台之所以能够生存下来,是因为它们可以适应现实。挑战在于,使它们有价值的可扩展性也使它们变得脆弱:每个定制都会成为未来的升级地雷,每个工作流程都是一个迷宫,每个屏幕都会对每个必须使用它的人征税。

这种脆弱性随处可见。尽管 CRM 得到了广泛采用,但用户对 CRM 的满意度仍然参差不齐,而且 ERP 中的高度定制始终与时间安排和预算超支相关。员工们正陷入碎片化的工作流程中 - 数字员工每天在不同的应用程序之间切换约 1,200 次(每周大约浪费 4 个小时),47% 的数字员工很难找到完成工作所需的信息。大规模的“转型”常常会遭遇挫折;据估计,大约70%未能实现目标。与这种摩擦相关的支出是巨大的:2023 年,仅软件实施/系统集成市场就约为 $380B

这里的过程和痛苦为人工智能提供了改变该软件的实现和使用方式的机会。了解机会的最简单方法是跟踪套件的生命周期:首先实施或迁移它,然后每天使用它,然后随着业务的变化在它的基础上进行构建。在每个阶段,工作都是将混乱的人类意图转化为针对记录系统的正确的、可审计的行动。

让我们考虑一下人工智能如何改进我们在每个阶段使用遗留软件系统的方式。

实施

让我们从实施开始——这是风险最高、预算最敏感的阶段,也是回报最明确的阶段。具体来说,这看起来像是将混乱的发现(会议、文档、票证)转化为结构化需求,然后自动生成实施工作流:流程和字段映射、配置和代码、测试脚本、切换计划和迁移手册 - 以及上线所需的数据清理和验证。这很难做到正确:众所周知,德国超市巨头 Lidl 在花费 5 亿美元后放弃了向 SAP 转型的努力。

这里的公司构建副驾驶、项目管理工具和其他软件来帮助迁移和实施。以下是该领域初创公司的一些示例(Andreessen Horowitz 投资了其中一些公司):

  • Axiamatic 是 ERP 的人工智能“保证”层:它根据项目工件构建知识图,并通过 Slack/Teams 标记需求/变更管理中的隐藏故障,以降低风险并加速 S/4HANA 计划(与 SAP Build 合作;纳入 KPMG/EY/IBM 动议)。

  • Conduct 是一个代码和流程映射副驾驶,可跨 ECC→S/4 生成语义层和技术文档,并通过自定义表格/API 进行问答以加快内部接管速度。

  • Auctor 为 SI/pro 服务进行代理实施交付,在成为 SOW、设计文档、用户故事、配置和测试计划的记录系统之前自动将发现捕获到结构化需求中。

  • Supersonik 帮助渠道/MSP 和客户实现人工智能驱动的产品 - 在真实 UI 中进行教学的视觉和语音代理,减少 SE 人员需求并实现经销商主导的实施/扩展。

  • Tessera 的 人工智能原生 SI 端到端管理企业转型 - 连接到客户现有的 ERP 实例,评估其实施方式,然后标记/自动修复迁移过程中需要更改的内容。

这些公司通过更快、更便宜、风险更低的转型来创造价值。他们通过几个关键方式做到这一点:在需求中及早发现问题并在滚雪球之前改变管理,压缩时间表(一个月的延误可能会花费数百万美元),将混乱的项目数据转化为结构化知识,以便内部团队可以更快地掌握所有权,并通过映射、文档、测试和支持的自动化来减少对大型 SI 团队的依赖。

我们看到更多初创公司有空间构建与现有合作伙伴合作而不是对抗的工具。具体来说:

  • 实施代理分担结果和风险(考虑需求跟踪、配置比较、切换模拟、代码生成和偏差检测)

  • 语义文档工具,使知识保持最新且易于访问

  • 支持代理将培训和渠道推出转变为可重复的产品

为什么世界仍然在 SAP 上运行

由于初创公司可以减轻企业级负担,因此他们可以根据避免的延迟进行定价,并将其投入到 CIO 和 CFO 已经支出的转型预算中,从而取代流程中臃肿的 SI 参与。

使用与维护

接下来,在实施软件套件后,使用它意味着要在这些软件套件目前混乱的用户界面中导航。日常工作跨越数十个屏幕,角色更替会重置专业知识,而且边缘案例工作流程的长尾永远不会得到一流的产品处理。用户花时间寻找字段,在系统之间镜像数据,并要求运营团队“只运行此报告”。其结果是周期时间缓慢、错误可避免,并且培训负担持续存在。

人工智能有机会用更友好、更强大的“行动系统”来包装遗留系统。

此类公司构建的工具可帮助团队从他们已使用的系统中获得更多收益。在实践中,这看起来就像是生活在 Slack 中的副驾驶或浏览器边车,可以回答“我在哪里可以找到 X?”或“我该怎么做Y?”使用语义搜索,然后在可用时通过 API 采取安全操作(创建案例、发布日记条目、更新供应商条款)。这些工具还可以将多应用程序工作流程链接在一起(“从 SAP 中提取上一季度的 PO,在 Coupa 中检查合同条款,在 ServiceNow 中起草差异说明”),并具有人工审批步骤、审计跟踪和精细的 RBAC。最好的跟踪采用情况、节省的时间和错误率。

企业中的许多重要工作仍然没有通过 API 清晰地公开 - 它们存在于屏幕、胖客户端、VDI 会话和半文档化的管理控制台中。这就是为什么现代“计算机使用”代理是 API 优先副驾驶的重要补充:它们将自动化的可触及范围扩展到工作流程的最后 30-40%,而在这些工作流程中根本没有可靠的端点可供调用。核心功能不是“单击按钮”,而是混乱情况下的可靠性 - 代理可以感知 UI、锚定到稳定元素、从弹出窗口和布局漂移中恢复以及检查点进度,以便它们可以在流程中安全恢复。当与验证(差异、协调、沙箱运行)和企业控制(SSO、秘密、最小权限、审计)配合使用时,这会将过去的手动工作转变为受监管的、可重复的自动化——票据分类、周期结算步骤、客户更新、定价变化——甚至在供应商从未为自动化构建的 SAP/ServiceNow/Salesforce 部分中也是如此。 API 使幸福之路变得更快,而计算机的使用使长尾自动化。

为什么世界仍然在 SAP 上运行

Factor LabsSola 等公司已经在生产中部署这些代理,取代 BPO 支出并帮助大型组织大规模自动化任务。

扩展

最后,即使您使 SAP/ServiceNow/Salesforce 变得更易于使用,您的业务也会不断变化,这意味着您的记录系统也必须随之变化。新产品、新政策、新收购、新法规以及长尾的工作流程永远无法证明核心模块项目的合理性,这意味着要不断努力使软件与您的业务实际状态保持相关性。从历史上看,团队有两种选择:定制套件(并继承脆弱性税)或构建一次性应用程序(并努力集成、管理和维护它们)。这是人工智能的第三个楔子:在记录系统之上快速交付小型、受监管的体验,同时保持核心清洁。

在遗留资产之上构建全新的工具和自动化成为不受欢迎的软件之上的“可爱”层。该模式从统一的数据和操作平面开始:通过 API 和事件(以及需要时的安全 UI 捕获)从记录系统读取,规范化为业务对象(订单、供应商、案例)的语义模型,然后通过 RBAC、批准和审计公开一组受管理的操作。

在这架飞机之上,团队提供了现代且专门打造的集中体验。您无需派遣采购分析师通过 12 个 SAP 事务来加入供应商,而是为他们提供一个“供应商加入”瘦应用程序,用于收集文档、检查重复项、路由审批并将正确的记录发布回 SAP。您无需要求 RevOps 打开五个 Salesforce 屏幕来更新续订条款,而是为他们提供一个电子表格速度的编辑器,可以批量编辑、根据策略进行验证、预览影响,然后通过完整的审核跟踪提交更改。您为一线团队提供了一个命令面板,而不是另一个“门户项目”,它可以回答问题并执行他们每天在多个系统中执行的少量操作(“创建回报”、“延长信用”、“打开 Sev-2”、“后应计”),而无需通过 20 个选项卡进行探索。

这些扩展还解锁了任何单一供应商都不会优先考虑的跨系统工作流程和自动化:事件驱动的触发器,例如“如果发票已过帐并且差异>3% → 起草解释 → 审批路线”,或“如果工单重新打开两次 → 创建问题记录 → 分配所有者 → 更新客户”,并在重要的地方设置人机循环检查点。随着时间的推移,最有价值的部署会变成可重复使用的“意图包”(报价到现金、供应商入职、周期结束),它们不仅编码要做什么,还编码如何在您的环境中安全地执行操作。

为什么世界仍然在 SAP 上运行

像 General Magic 的 Cell 这样的平台使构建这些定制工作流程的构建块变得有形:您上传 OpenAPI 规范,以便每个端点都成为一个操作,然后嵌入一个带有单个脚本标记的本机命令栏,该脚本标记执行真正的 API 调用,并由分析、多租户、安全护栏和 RBAC 提供支持,因此工作从重建另一个 UI 转变为在您已经信任的系统之上编写正确的操作和策略。

结局是什么样的?

我们认为遗留系统大部分会持续存在,但它们将不再是工作发生的表面区域。 ERP、CRM 和 ITSM 套件嵌入得太深,无法按照典型的软件节奏进行剥离;它们发展缓慢并且仍然是记录系统。将会改变的是位于顶部的面向用户的“行动系统”:人工智能将成为默认界面,用于发现系统如何工作,在系统中执行工作流程,并提供完全绕过旧版 UI 的小型现代体验。换句话说,桥梁变成了高速公路。

此类别中的持久软件看起来不太像聊天机器人,而更像操作层:具有业务对象语义模型的统一数据和操作平面,以及使人工智能在生产中值得信赖的护栏。如果您是最终用户,您无需学习要使用哪个屏幕、字段和事务代码(然后在每次 UI 或流程发生变化时重新学习),而是描述您想要的结果,系统就会帮助您实现目标。您将提出几个澄清问题,预览它将要执行的操作,然后该工具将在正确的批准和审核跟踪下执行。关闭循环看起来像“创建退货并通知客户”、“打开 Sev-2 并提取最后三个相关事件”或“加入该供应商、收集文档、进行审批并设置付款条件”——如今需要跨 SAP、Salesforce、ServiceNow 和电子表格进行操作。这使我们减少了错误和逆转,减少了对部落知识的依赖,缩短了周期时间,并显着降低了培训负担,因为该界面默认是意图驱动、角色感知和自助服务。

护城河由实际使用组成:每个成功的工作流程都成为可重用的意图,每个异常都成为护栏,每个迁移工件都成为活生生的血统,每次集成都加深了企业实际运行方式的图表。随着时间的推移,“AI 层”成为团队了解变革影响、防止偏差、衡量投资回报率和交付新工作流程的地方,即使底层系统保持不变。

[

](https://substackcdn.com/image/fetch/$s_!x83d!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2 F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbdfa26cc-8980-41ca-a3bb-7ece793bed5b_3098x158.png)

本新闻稿仅供参考,不应被视为法律、商业、投资或税务建议。此外,本内容并非投资建议,也不适合任何 a16z 基金的任何投资者或潜在投资者使用。本新闻稿可能链接到其他网站或包含从第三方来源获得的其他信息 - a16z 尚未独立验证也不对此类信息的当前或持久准确性做出任何陈述。如果该内容包含第三方广告,a16z 并未审查此类广告,也不认可其中包含的任何广告内容或相关公司。提及、提及或描述的任何投资或投资组合公司并不代表 a16z 管理的车辆的所有投资;请访问https://a16z.com/investment-list/获取完整的投资列表。其他重要信息请访问 a16z.com/disclosures。由于您之前选择加入,因此您会收到此新闻通讯;如果您想选择不再接收未来的时事通讯,您可以立即取消订阅。