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、交付新工作流的目的地——即便底層系統保持不變。