AI 讓每個人都能做系統之後，企業數位轉型真正缺的是什麼？
AI讓懂業務的人也能打造工具，但企業數位轉型的挑戰，才正要開始。當各部門都能建立應用，如何維持一致的資料、權限與流程？本文從系統的長期責任出發，探討自建與平台的分工，讓企業在應用增加時，仍能維持可信的業務秩序。
AI讓懂業務的人也能打造工具，但企業數位轉型的挑戰，才正要開始。當各部門都能建立應用，如何維持一致的資料、權限與流程？本文從系統的長期責任出發，探討自建與平台的分工，讓企業在應用增加時，仍能維持可信的業務秩序。
AI 降低了企業製作應用的門檻，卻不會自動解決資料一致性、權限控管、流程變更與維護交接。當更多部門自行建立工具，數位轉型的下一步，不是再多幾個 App，而是把散落各處的資料、權限、流程與決策，整理成人與 AI Agent 都能遵守的「受治理的業務狀態」（Governed Business State）。
上一篇〈程式碼變便宜之後，誰來承擔軟體的責任？〉，我們從顧問業產品化談起：當懂客戶流程的人能用 AI 做出應用，原型之後的持續維護、產品演進與服務責任，應該由誰承接？
這一次，把視角轉回企業內部。
假如財務、HR、業務與營運，都有能力建立自己的工具，企業要怎麼確保它們依然使用一致的資料、遵守同一套制度？
當每個人都能做系統，企業真正缺的，是維持共同業務秩序的能力。
Vibe Coding 讓懂工作的人，更容易創造工具
過去想改善一個流程，往往要先整理需求、排資訊部門的時程，或找廠商討論規格。現在透過 Claude Code、Codex、Grok Build 等 AI 開發工具，理解業務的人有機會更快把想法變成原型。
這裡所說的 Vibe Coding，是指透過自然語言與 AI 反覆協作，快速探索和建立應用；能做出原型，不代表已完成正式上線所需的驗證。
這種能力很有價值。最清楚工作卡在哪裡的人，終於不必等到一切規格都確定，才能拿出東西和同事討論。
但試想一個情境：業務做了客戶查詢工具，財務做了請款追蹤表，HR 又建了一個回答員工問題的 Agent。每一套單獨看都很合理，也確實解決了眼前問題。
當這些工具開始一起運作，新的問題才會出現：客戶名稱以哪裡為準？員工調部門後，哪些資料還能看？請款顯示「已核准」，究竟代表主管同意，還是已經可以付款？
這些問題需要企業明確決定，也需要系統持續執行。
AI 降低建置成本，沒有讓長期責任消失
一套系統的成本，不只第一版的開發。
制度修改、組織調整、資料搬遷、權限更新、整合異常、版本相容與人員交接，都會在系統的生命週期中持續發生。AI 可以協助處理其中很多工作，但不會自動決定誰應該負責，也不能代替企業確認制度是否正確。
Build Cost 可以下降，Ownership Cost 仍然需要管理。
這裡的 Ownership Cost，指持續持有、營運與改善系統所需的投入。即使單一工具更容易維護，工具數量快速增加，整體管理負擔仍可能上升。
過去的 Power User 問題，是「這個系統只有一個人會操作」。未來則會變成「這些 Agent、工作流程、資料庫與 API，只有當初建立的人知道怎麼串」。
問題不只在程式碼，更在於散落在個人腦袋、文件與 Prompt 裡的業務規則。
企業應該鼓勵同仁用 AI 改善工作，同時讓工具有負責人、資料有權威來源、流程有明確規則。否則，今天生成的便利工具，會成為明天沒有人敢改的舊系統。
從 System of Record，走向受治理的 Business State
企業建立 CRM、HCM、ERP 與 BPM，其中一個目的，是確認資料與交易以哪裡為準，也就是 System of Record 的角色。
成熟的企業系統本來就包含流程、權限與狀態。當 Agent 開始跨系統工作，新的要求是：把這些規則與可執行動作表達得更清楚，讓不同介面與 Agent 操作時，仍然遵守相同限制。
本文用 Governed Business State，也就是受治理的業務狀態，描述這個方向。這是我們思考 Vital 下一階段平台的框架，並非宣稱一個已定案的產業標準。
它不只回答「資料是什麼」，也回答「現在發生到哪裡、誰可以採取什麼動作，以及這個決定如何被追溯」。
以出差申請為例，可以從八個面向理解：
| 面向 | 需要說清楚的事情 | 出差申請的例子 |
|---|---|---|
| Data｜資料 | 有哪些資訊 | 申請人、日期、地點、預估費用 |
| Semantics｜語意 | 資訊代表什麼 | 預估費用是否包含住宿與交通 |
| Relationship｜關聯 | 與哪些對象有關 | 部門、主管、成本中心與案件 |
| State｜狀態 | 目前進行到哪裡 | 草稿、送審、核准、退回、取消 |
| Policy｜政策 | 誰在什麼條件下可操作 | 可讀範圍、核准權限與超額規則 |
| Process｜流程 | 允許哪些下一步 | 草稿可送審，退回後可修改再送 |
| Decision｜決策 | 決定根據什麼 | 政策版本、例外理由與核准依據 |
| Audit｜稽核 | 誰做過什麼 | 員工或 Agent 的操作時間與紀錄 |
共同可信，不代表所有資料必須搬到同一個資料庫。HR 可以維持員工資料的權威來源，CRM 管理客戶主檔，流程系統保存申請狀態；關鍵在於來源、關聯、同步方式與修改責任都清楚。
「幫我申請出差」之後，Agent 應該知道什麼？
員工對 Agent 說：「幫我申請下週的出差，照公司規定處理。」
Agent 先在授權範圍內取得員工資料，整理日期、地點與費用，確認缺漏資訊，再依有效政策建立申請。送審之後，案件交給有權核准的人；Agent 不會因為員工說「照規定處理」，就自己把狀態改成核准。
如果費用超過門檻，就走相應的加簽或例外程序。如果員工已調部門，就依企業設定的適用規則決定簽核對象。如果外部系統回應逾時，也必須先確認案件是否已建立，避免直接重試造成重複送單。
每一次狀態改變，都應能追溯執行者、授權關係、適用規則與執行結果。
今天員工可能使用表單，明天改用對話介面，之後又換了另一個模型。但同一張申請的狀態、權限與決策依據，不能隨著介面更換就重新生成。
自建還是採購？Ohalo 的選擇是把兩者接起來
這個方向不只是我們的推論，市場上已經有企業走過一遍。
在 2026 年 8 月 26 日 Salesforce 財報直播中，Ohalo CEO David Friedberg 分享，他曾用一個週末嘗試 Vibe Coding CRM，隨後發現維護、帳號與安全還有大量工作。Ohalo 後來選擇 Salesforce 作為 CRM 平台，繼續自行開發植物育種、農戶開發與產品選擇等差異化應用，再與平台串接。[1]
這個案例最值得注意的是：他們沒有放棄自建，而是重新劃定自建的範圍。能讓公司創造差異的流程，值得自己投入；共通的客戶紀錄與存取管理，則交給成熟平台承接。決策不必只有「全部自己做」和「全部交給廠商」兩種選項。
平台廠商也在往同一個方向移動。Retool 在 2026 年 6 月 17 日公告，讓不同 AI 工具生成、或由 React 程式碼匯入的應用，在平台上承接既有權限、稽核與資源政策。[2] 建置入口可以很多個，但正式運作時遵守的規則只有一套。
上一篇從供應商角度，討論這些共用能力如何降低重複維運。本篇更關心的是：當企業擁有多種建置入口，是否仍能維持一致的執行規則？
平台能承接共同控制，仍需要企業與導入團隊把資料來源、角色權限及業務規則設定清楚。開放 API 或 MCP，是讓 AI 接近工具的一步；操作是否被允許，必須由可執行的規則把關。
做得到之後，更值得問的是：這件事是否值得由我們長期經營？
企業應該自己做什麼，讓平台承接什麼？
判斷的起點，是業務差異、風險與長期承接能力。
| 情境 | 可以採取的方向 |
|---|---|
| 小範圍、低風險、可丟棄的驗證工具 | 先自行建立原型，確認是否有用 |
| 公司獨有的分析、介面或業務流程 | 評估自建，連接既有資料與平台 |
| 共用主檔、多人權限、核准或交易紀錄 | 先建立共同治理，再開放介面擴充 |
| 需要長期專業更新與持續支援 | 先問三年後內部還有沒有人能接手；沒有，就交給平台承接 |
採購同樣有訂閱、整合、客製與退出成本。平台必須證明它減少的複雜度，值得企業支付的代價。
責任也需要明確分工：企業決定制度與核准權責；建置或導入團隊負責正確實作與驗證；平台供應商依服務範圍承接共通能力和營運。使用者與 Agent 則在授權範圍內執行工作。
購買平台，不等於把企業自己的責任一起交出去。
從產品持續經營，到企業制度持續可信
上一篇談到，軟體公司的長期價值，是把客戶現場的需求整理成可共用的產品能力，透過顧問、業務、客服與研發持續協作，讓產品不斷改善。
當這些能力進到企業內部，還需要與企業自己的資料、組織和制度接起來。一邊累積產品經驗，一邊維持業務秩序，兩者共同支撐的，是讓企業能安心增加應用，而不必每做一個工具，就重新定義一次客戶、員工、核准與責任。
對照前面的八個面向，Vital BizForm 今天已經在做其中三個：狀態（State）由流程引擎管理，流程（Process）由簽核規則定義，稽核（Audit）留在每一筆操作紀錄裡。接下來要補的，是把語意（Semantics）與政策（Policy）也表達成 Agent 讀得懂、執行時會遵守的形式——讓「照公司規定處理」這句話，真的有一套規定可以照。
數位轉型成熟的標誌，不在於公司有多少 AI App。而在於即使應用不斷增加、人員不斷更替、模型不斷改變，企業依然知道資料以哪裡為準、現在發生什麼事，以及誰應該為下一個動作負責。
企業真正需要累積的，是持續可信、可治理，而且能被安全操作的 Business State。
如果你的企業正在思考怎麼讓 AI 進入日常工作，可以先選一個真實流程，例如出差、請款或採購申請，用上面八個面向盤點它的資料來源、操作權限、核准條件與交接責任，再決定哪些交給 AI，哪些由平台承接。
資料來源與延伸閱讀
- Ohalo CEO David Friedberg 訪談：Salesforce FY27 Q2 財報逐字稿，2026/8/26，約 25:23–28:00。客戶在供應商財報場合的第一人稱分享，逐字稿由第三方刊載。
- Retool：Extending enterprise governance to AI-coded apps，2026/6/17。供應商官方公告。
系列上一篇：〈程式碼變便宜之後，誰來承擔軟體的責任？〉，從顧問產品化、持續營運與產品演進，討論軟體責任如何被長期承接。