擴大 AI 原型之前，先讓一個工作流程接上真實的企業資料

模擬資料很寬容，您的 ERP 可不會。用虛構紀錄做出來的原型，證明的是這個點子做得出來，而不是您的企業能靠它運作。在投入資金擴大 AI 自動化之前，請要求一個工作流程先以您的真實紀錄、權限與例外情況，完整跑完端對端流程。唯有在流程負責人依照事先約定的結果認可其成果之後，才擴大導入。

一支工程團隊的實際經驗

Atlassian 在 2026 年 8 月 26 日發表了一篇文章，記述一支 5 人團隊如何把一個週末做出來的原型推上正式環境。大約 15 小時、約 250 次 AI 代理工作階段，以及 100 次以上的審查退回，產出了「一個搭配真實資料庫、可以實際運作的應用程式」，但它的基礎是「對實際整合、身分驗證與使用者角色（persona）推導採用可接受的模擬」（Atlassian）。

問題在模擬被替換掉之後開始浮現。團隊寫道：「真實的資料結構（schema）與模擬的不一樣」，而且資料無法單純轉換過去，因為原型「已經內建了錯誤的假設和大量捷徑」。此外，每一個 pull request 都會改動原本用來鎖定既有行為的端對端測試，「這完全失去了設置這些測試的意義」。團隊的結論是：「瓶頸在於人所掌握的脈絡」（Atlassian）。

團隊後來靠縮小問題範圍重回正軌：挑選一個幾週內就能交付的功能，並在任何 AI 代理動手之前，先在規劃階段把邊界案例的問題釐清，而且「完全不靠 AI 這根拐杖」（Atlassian）。團隊表示，大約 5 個月後成功上線到正式環境，而據其描述，每位工程師的產出約為同類傳統開發方式的 5 倍（Atlassian）。

這說明了什麼，又沒有說明什麼

這是一支團隊用 AI 開發軟體的經驗，不是在 ERP 內運作的 AI 代理，也不是失敗率統計。這個教訓之所以適用，是因為斷點出現在同一個地方：當描述企業的模型碰上真實的企業時。TechTarget 在 2026 年 2 月報導，部分 AI 專案「一接觸真實世界的資料就出狀況」。在一個得來速的例子中，一位顧客點了 18,000 杯水，「而 AI 系統就照單全收地輸入了」（TechTarget）。

SAP 旗下 Reltio 的執行長 Manish Sood，在 SAP News 於 2026 年 9 月 23 日刊出的專題報導中表示：「AI 展示可以容忍資料中大量的瑕疵與缺口；在真實企業情境中運作的 AI 代理則不行」（SAP News）。該文引述 Harvard Business Review Analytic Services 的研究：受訪組織中有 94% 正在探索或導入代理式 AI（agentic AI），而 15% 認為自己的資料基礎已真正準備就緒（SAP News）。我們並未看過這項調查的樣本與研究方法。

我們建議的擴大導入關卡

以下五項檢查是我們根據上述案例提出的建議。第一個工作流程必須全數通過，第二個工作流程才能取得預算。

1. 真實紀錄。 工作流程讀寫的，必須是正式上線時會用到的實際 ERP 資料表、客戶紀錄與料號。匯出檔或範例資料結構都不算數。
2. 真實權限。 以該職務的實際使用者所擁有的存取權限執行。如果原型需要系統管理員權限才能運作，那它其實還沒有成功。
3. 明確列出的例外。 團隊已列出工作流程必須拒絕處理或轉交人員處理的情況，並逐一測試。
4. 獲得認可的結果。 在執行之前，流程負責人已先同意怎樣才算正確的結果，例如一張完成比對的發票或一筆經確認的訂單明細，之後再核准一批具代表性的結果。
5. 明訂的人工步驟。 任何涉及金錢或庫存移動、或會讓您對客戶做出承諾的動作，都要等指定人員核准。正如 Sood 所說：「界定 AI 代理可以在哪裡行動、人需要在哪裡介入，以及決策如何追溯」（SAP News）。

衡量重工，而不是產出量

Atlassian 的原型大約 15 小時就能運作；約 5 個月的時程中，大部分都花在那之後（Atlassian）。與其追蹤程式碼數量，不如追蹤這兩個數字：

• 整合重工： 為了讓工作流程配合您的真實資料與存取規則，所需要做的修改。
• 獲得認可的結果： 流程負責人不需修正就直接核准的結果所占比例。

如果重工量沒有隨著每一次執行而減少，原型對您企業的描繪很可能是錯的；請先修正這一點，再增加 AI 代理。

最有力的反對意見

設下關卡會拖慢正在衝刺的團隊，而且低成本的原型能及早暴露需求。但這道關卡並不會阻止任何人做原型。它阻止的，是公司基於同一套假設同時資助好幾個原型，而這些假設只有一次真實的整合才能驗證。

我們的做法

我們把一個工作流程的實際紀錄、權限與例外情況，描述在一個共用的企業模型中，並讓 AI 代理連接這個模型，而不是連接模擬資料。涉及金錢或商譽的動作，一律保留由人員核准。是否擴大導入，取決於第一次執行所得到的證據。

您的第一週

• 第 1–2 天： 挑選一個停滯不前的原型，以及它應該銜接的 ERP 步驟。寫下流程負責人會認可的結果。
• 第 3 天： 列出這個工作流程需要的真實資料表與使用者角色。
• 第 4–5 天： 向負責處理例外的同仁收集上個月的例外情況；決定哪些必須交由人員處理。

本季請核准一項端對端整合，而不是全面推行。如果它通過五項檢查，而且重工減少、獲得認可的結果增加，就資助下一個工作流程。如果沒有通過，您也只用一個工作流程的代價就找到了問題，而不必賠上好幾個。