文／葉宏謨
1960 年代至 1990 年代之前，企業資訊系統都是量身打造的，稱為內部設計（In-House Design）系統，1990 年代之後才有套裝 ERP 系統出現。企業用戶需求多變，套裝 ERP 系統的「用戶體驗」(User Experience, UX）極差，多數使用者只能勉強接受。
到了 2000 年代，有了 SOA 的概念和方法，寶盛數位科技把 ERP 系統拆成上萬個SOA 軟體元件，「自軟體」小團隊或個人軟體公司才能發揮所長，組裝軟體元件為各產業開發產業別應用程式，或為個別企業用戶客製專屬的應用程式，形成企業軟體生態系。SOA 軟體元件沒有 UI 只有 API，利用軟體元件組裝出來的應用程式才有 UI，因此軟體公司可「隨意客製」用戶體驗絕佳的應用程式。
一、ERP 軟體元件化
1980年代，筆者曾服務於復盛集團，那時的資訊系統是自行開發的，包括銷售和會計等多套系統。印象最深的是，因為各自有資料庫，銷售系統和會計系統的銷貨收入永遠對不起來，也不知道哪個數字才正確。後來用了 ERP 系統才解決了這個問題，但又帶來了用戶體驗（UX）極差和客製化困難的問題，畢竟套裝 ERP 系統不是為自己設計的，和真正的需求有一段差距，又很難客製修改，使用者會抗拒。
1996年，Gartner 提出 SOA 的觀念，2003年從復盛分拆出來的寶盛開始研發 SOA 服務元件，將 ERP 系統的功能設計成沒有 UI 只有 API 的軟體元件，終於能兼顧資料整合和彈性客製的問題，至今已累積近萬個軟體元件。用戶體驗（UX）只和使用者介面（UI）及商務流程（BP）有關，各產業都能利用組裝 SOA 服務元件客製出使用者想要的流程和介面應用程式。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
SOA 服務元件背後有「企業統一資料架構」(Enterprise Unified Data Architecture, EUDA）的單一資料庫，應用程式不直接存取資料庫，而是透過 SOA 服務元件。SOA 服務元件是可彈性組合的積木，EUDA 是穩固的企業通用資料架構，合起來稱為「新企業協作」(Neo Enterprise Orchestration, NEO）。
NEO 有「服務組合」(Service Composition）的服務，能並聯或串聯多個服務元件，彈性組合服務元件客製應用程式，讓企業得到所需要的用戶體驗。軟體公司，包括由小團隊或個人組成的「自軟體」開發者 [註 1]，可組裝 SOA 服務元件推出自己的 ERP 產品，目前已有軟體公司（擎天）用 NEO 的 SOA 服務元件開發出醫療業的 ERP 系統。
二、應用系統不應該有非公開資料
企業應該擁有自己的「資料主權」(Data Sovereignty）[註 2]，也就是企業的非公開資料不應該放在 ERP、CRM、或 HRM 等應用系統中，應該放在自己能掌握的資料庫中，例如 NEO EUDA 資料庫。
以 HRM 為例，HRM 系統應該只有勞健保級距這種公開資料或員工打卡資料，員工薪資不應放在 HRM 系統，應該放在 NEO 中，而且和薪資有關的服務元件只有老闆才有權限叫用。例如 HRM 有勞健保級距費率，但每位員工的本薪、津貼、獎金、投保級距等資料都在 NEO。
HRM 在計算薪資時，從 NEO 讀入個別員工的相關資料，查出保險費率，算出薪資，再寫回 NEO，HRM 只計算薪資不儲存薪資資料。企業在 NEO 維護本薪津貼等非公開機敏資料，HRM 軟體公司則負責維護勞健保級距費率等公開資料。非公開機敏資料只在計算薪資時暫時讀入 HRM，不會永久存入 HRM 的資料庫。企業只要保護好放在地端的 NEO，就算放在雲端的應用系統被駭入，也不會洩漏機敏資料。
NEO 的 SOA 服務元件涵蓋製程、作業、資源(人或機）、標準工時等主資料，但作業的資源耗用資料則存在於有感測裝置能自動收集交易資料的製造執行系統（MES）資料庫中。MES 資料庫和 NEO 的 EUDA 資料庫的交集只有作業和資源代號，因為主資料是由 NEO 發動並同步維護 MES 的，MES 除了代號之外，作業和資源的相關主資料（例如名稱、標準工時等其他系統也會用到的資料）都從 NEO 取得。MES 計算交易資料，例如各資源的即時耗用數量，彙整後再回報 NEO。
[ 瀏覽葉宏謨所有文章 ]
有些應用系統只需維護公開資料沒有機密資料，例如計算產品碳足跡的系統。因為 NEO 本身就已包含材料表、製程、作業、資源等相關資料的 SOA 服務元件，以及成本分攤和成本滾算的服務元件，碳足跡應用系統只需維護各國碳係數等公開資料的資料庫，不需另外建立企業的私有資料，每個月底只需按一個鍵就能根據 NEO 本來就有的資料自動計算出企業或整條供應鏈的產品碳足跡資料。
有些應用系統完全不需要資料庫，例如計算未來應採購或製造多少材料或產品的 MRP 系統，只要定期自動匯入企業資訊系統的材料主資料，以及庫存、銷售預測、在途單據等水位和交易資料，就能產生未來的計劃訂單（Planned Order）和行動訊息（Action Message），這個MRP 應用系統就完全不需要資料庫了。
除了公開資料（例如碳係數、勞健保級距）可儲存在應用系統的資料庫之外，所有由各個軟體公司所開發的應用系統都應該共用 NEO 的 SOA 服務元件和 EUDA，不要有企業的機敏資料庫，才能彈性組裝元件快速客製應用程式，且不會有資訊安全、資料重複、不一致、不整合的問題。軟體公司可專注於各產業、各規模企業所需要的用戶體驗，開發用戶體驗極佳的應用系統。應用系統必須做到該產業使用者看到就會操作，不需要導入顧問，也不需要操作手冊，這樣才能算是好的用戶體驗。
軟體公司開發新的應用程式時，應專注於用戶體驗，不要管資料庫，開發介面（UI）和流程（BP）叫用現成的 SOA 服務元件即可。軟體元件不夠用時可請開發元件的寶盛公司增加新元件，開發應用程式的軟體公司不需要自己開發元件，正如開發 3C 產品的公司絕對不會自己開發電子元件一樣。當各個軟體公司開發應用程式不再需要資料庫時，企業應用軟體就不會有資料無法整合的問題，且能快速的組裝出使用者需要的、有完美用戶體驗的應用程式。
三、軟體元件結合人工智慧
要達到各個軟體公司所開發應用系統不要有機敏資料庫，還有一段很長的路要走，在此之前必須整合各軟體公司應用系統的資料庫。
企業可結合 SOA 服務元件和人工智慧（AI）來整合不同應用系統的資料。企業利用 AI 來分析各系統的資料架構時，若應用系統有 API 則可分析各系統的 API 和 SOA 服務元件 API 的對照（Mapping）關係，再由 AI 開發程式定期叫用 SOA 服務元件 API 同步各系統的資料；若應用系統沒有 API 則 AI 可分析資料庫結構和 SOA 服務元件 API 的對照關係，AI 定期從資料庫匯出 Excel 檔，叫用 SOA 服務元件 API 同步各系統的資料。
企業應用的開發就是找到 SOA 服務元件和設計樣式（Design Pattern），開發操作介面（UI），並在 UI 中呼叫 SOA 服務元件。企業應用的用戶體驗設計（UXD）比消費型應用更複雜，不同產業、不同公司、不同使用者、不同時間點所需要的用戶體驗都不一樣。軟體公司可針對各種使用情境，開發各種設計樣式的 UI/UX 程式，AI 就能根據使用者說出的需求，找到合適的 SOA 服務元件和設計樣式，填入服務元件的輸入參數和輸出欄位的關鍵字（KEY），完成應用程式的開發。
有了 SOA 服務元件和 UI/UX 設計樣式，加上 AI 的系統分析和 AI 的程式設計，企業應用程式的開發很快，軟體公司可以迭代開發展示各種不同用戶體驗的應用程式讓使用者選擇。因為企業資料都在 NEO 的 EUDA 中，企業擁有資料主權，使用者可以隨時更換功能相同、用戶體驗不同的應用程式，創造更健康的軟體生態系。
四、人工智慧與前線部署工程師
多年前筆者服務於復盛集團時，資訊部門的工程師一定要到現場和作業者一起工作一段時間，了解使用者真正的需求，培養同理心（Empathy），才能開發出用戶想要的應用程式。到了 AI 時代，用戶的需求更廣，不再只是資訊系統的操作，而是心中構想的實現，軟體工程師更需要和現場人員一起工作，稱為「前線部署工程師」(Forward Deployed Engineer, FDE）。
根據 MIT Project NANDA 調查 500 多家企業後發現，高達 95% 的生成式 AI 專案無法對公司損益產生可衡量（Measurable）的影響 [註 3]，原因是 FDE 不足。
FDE 成本相當高，只有大企業才負擔得起，但中小企業也有 AI 應用的需求。自軟體生態系中的個人開發者遍佈各地，佔地利之便，個人開發者可駐點在附近的中小企業，和使用者打成一片，了解使用者內心的想法，成本也比較低。自軟體開發者最重要的能力是同理心，須能從用戶角度思維、對用戶的需求作價值判斷、針對用戶想要的體驗，設計 AI 應用 [註 1]。
五、結論
1990年代之前企業資訊系統都是量身打造的「內部設計」系統，必須自己開發和維護。1990 年代之後才有套裝的 ERP 系統，雖然不用自己開發、維護，但無法根據自己的需求設計系統。2000 年之後軟體公司利用 SOA 服務元件開發各產業應用程式，再加上針對個別企業的客製化應用程式，讓企業不用自己開發、維護也能擁有自己的專屬 ERP 系統。每個企業都不一樣，本來就應該使用獨一無二的專屬 ERP 系統，才會有好的用戶體驗。
參考文獻
[註 1] 葉宏謨，自媒體與自軟體，CIO Taiwan，2026年6月7日。https://www.cio.com.tw/114495。
[註 2] 葉宏謨，資料主權，CIO Taiwan 專欄，2025年12月31日，https://www.cio.com.tw/104753。
[註 3] 何信達，FDE 前線部署工程師：讓 AI 真正落地的角色，CIO Taiwan，2026年5月31日。 https://www.cio.com.tw/114052。(本文授權非營利轉載，請註明出處：CIO Taiwan)
