台灣企業軟體的產品及服務策略
數位發展部強調軟體產業要具規模化與國際競爭力，應以產品為主。企業軟體需求多變，本文提出系統模組化、模組元件化與單一模組逐步導入的策略，兼顧標準化與客製化。
文‧圖／葉宏謨
數位發展部部長林宜敬在 2025 年 11 月時表示，要讓台灣軟體產業具規模化與國際競爭力，唯有做產品，屬於產品導向，專案導向居次 [ 註 3]。
個人軟體是給個人用的，企業軟體是給組織用的，差異很大。個人軟體不論是找路、查時刻表、查天氣、買東西、交朋友……，所有人的需求都一樣，不需要導入也不需要客製，當然可以做成產品；企業軟體完全不一樣，不同產業、相同產業不同公司、相同公司不同使用者、相同使用者在不同時間都會有不同的需求，所以企業軟體一定需要客製。
[ 加入 CIO Taiwan 官方 LINE、Facebook 與 LinkedIn，與全球 CIO 同步獲取精華見解 ]
個人軟體不需要上課大家都會用，也不需要提供導入服務；企業軟體牽涉到的人、事、物太多，流程很長，各部門使用者都必須接受教育訓練，才能了解如何操作軟體以及如何和其他使用者配合，必須經過冗長的導入程序才能上線，「以產品為主，專案為輔」實在太難。
為了讓台灣企業軟體變成產品，本文提出「系統模組化、模組元件化」的產品策略，以及「單一模組、逐步導入」的服務策略。
一、產品策略：系統模組化、模組元件化
軟體公司必須站在企業的立場，設法解決企業在經營管理上使用軟體的問題。常見的企業軟體包括企業資源規劃（ERP）、客戶關係管理（CRM）、人力資源管理（HRM）、製造執行（MES）、銷售點（POS）、供應鏈管理（SCM）等系統，其中範圍最廣、最複雜的是 ERP 系統。以 ERP 系統為例，目前市場上的企業軟體大多數是複雜而僵硬的，欠缺能重複使用的軟體元件，產品無法多樣化，軟體公司很難幫客戶客製應用程式，使用者必須削足適履，遷就 ERP 系統的既有功能。
家電、汽車、和電腦等產品早已模組化，使用者需求千變萬化的 ERP 系統更需要模組化、元件化。以電腦為例，一部電腦包含主機板、顯示卡、記憶體、儲存裝置、鍵盤、滑鼠、外殼、電源供應器等模組，這些模組又由 CPU、GPU、RAM、ROM、SSD 等積體電路元件和電容器（Capacitor）、電阻器（Resistor）、電感器（Inductor）等被動元件組成。家電、汽車、和任何其他硬體產品也是一樣，都是系統模組化、模組元件化的產品。元件、模組、系統都是由不同公司生產，再經由供應鏈提供給客戶。但是，ERP 系統至今仍然做不到，皆由單一公司提供，屬於單一供應商模式，有別於供應鏈模式。電腦鍵盤壞了換個鍵盤就能瞬間解決問題，但是，企業所使用的 ERP 系統若不能算出正確的產品成本，卻不能換個成本模組就解決問題。
筆者服務的公司從二十多年前就開始研發如同積木般可以組裝成各種企業應用軟體的服務導向架構軟體元件，稱為「新企業協作」（NEO）平台，包含上萬個 SOA 微服務元件和「企業統一資料架構」（EUDA）資料庫 [ 註 1]。NEO 沒有使用者介面（UI），但每個 SOA 服務元件都有程式介面（API），目的是讓軟體公司能組裝 SOA 服務元件快速開發應用程式，以改善企業的經營、管理、和作業。軟體公司可以用任何程式語言叫用 SOA 服務元件，組裝出使用者需要的商務流程（Business Process, BP）以及使用者介面（UI），也就是前端應用程式。一個領域所需要的一群應用程式稱為應用程式模組（例如採購與付款循環），多個模組即構成一個企業應用系統（例如九大循環模組構成 ERP 系統）。每個企業都有九大循環，他們的前端應用程式所需的 BP 和 UI 都不一樣，但都可以利用 NEO 的 SOA 服務元件組裝而成。前端應用程式、應用程式模組、應用系統都可由不同的軟體公司生產，並透過供應鏈提供給企業。因為都是用 NEO 做出來的，所以企業的應用系統可選用不同軟體公司生產的應用程式模組，和電腦、家電、汽車一樣。
管理是一種藝術，更是一門放諸四海而皆準的科學。管理的本質就是在調換組織的資源，讓組織更強大。企業不能靜止，必須不斷改變，把企業資源變成產品或服務、把產品或服務變成資金、把資金變成設備和員工福利創造更有效率的工作環境、吸引更多優秀員工加入組織、…。NEO 根據管理的本質，取材 APICS／ASCM （Association for Supply Chain Management）的架構，參考 SAP 和 Oracle 等國際級產品的作法，以及在台灣集團企業多年的製造業實務經驗，設計出「企業統一資料架構」（EUDA），並在其上建立了近萬個 SOA 服務元件，依流程分成近千個組件（Use Case, UC），各流程都會共用的服務元件放在核心組件（UC_CORE），使用 NEO 的企業一定要安裝核心服務組件，其他服務組件（UC）則可以視需要單獨安裝，如圖 1。
所有服務組件和 EUDA 構成 NEO 系統，NEO ERP 取 NEO 各組件（UC）中的元件做出各種前端應用程式（例如採購單維護、採購系統轉單、…），再把相關應用程式放在一起做成模組（例如採購、銷售、會計、製造、…模組），所有模組構成了產品（例如 ERP 系統）。所以，NEO ERP 也是系統模組化、模組元件化的產品，和電腦、家電、汽車一樣。
電腦、家電、或汽車沒有客製化的問題，但企業應用系統為了因應多變的使用者需求，必須能快速客製化。用 SOA 服務元件組裝而成的企業應用系統本來就可以拆開重組、抽換應用程式模組。若找不到適用的應用程式模組，則可利用 NEOGen 生成新的微服務元件，客製出能滿足使用者需求的應用程式模組。依特殊性由小而大，前端應用程式模組可分為標準模組、產業別模組、和個別企業的客製化模組，這些應用程式模組構成了每家企業的專屬 ERP 系統。每家企業都可以有、也應該有其專屬的應用系統。如圖 2。
NEO 的 SOA 服務元件並非萬能，但它可無縫整合其他服務元件。例如農田水利灌溉系統，應用程式讀入水文和氣象資料，利用 NEO 的規劃服務元件（UC_PLAN），整合各地水庫和全台灣 2000 多處管理站的感測器資料，就能讓水資源獲得最有效的利用。再例如，工廠生產線有自動判別品質的感測裝置，本身就有提供 API，應用程式可呼叫感測裝置的 API 和 NEO 的製造模組服務元件 API，將品質資料整合到 EUDA 中。企業中的每一部機器、儀器、或感測器都有 PLC 程式可存取資料，因為 PLC 程式可呼叫 SOA 服務元件，NEO 可作為各地點、各設備的資料交換中心。
很多風景區都有「租腿服務」，遊客租了「外骨骼機器人」就能健步如飛，那是因為人的架構都一樣。每個企業都有多套應用系統，因為資料架構不一樣，所以沒有辦法像租腿那樣，今天租一套應用系統明天換租另一套應用系統，企業資料被綁架在各應用系統中。NEO 的目的是透過 SOA 服務元件將各應用系統的資料都同步整合到 EUDA 中，企業才能真正擁有自己的資料，而不會被應用系統綁架。人擁有自己的腿，不論在哪個景點，遊客都不用租特定廠牌的「外骨骼機器人」。企業若能擁有自己的「資料主權」[ 註 1]，就能隨時更換應用系統或應用程式模組。
每個企業都有其特殊的需求，軟體公司可利用現成的標準應用程式模組和 SOA 服務元件為個別企業打造專屬的 ERP 系統。軟體公司也可以開發自己的服務元件和應用程式，以提升客戶服務的品質和速度。軟體公司的規模不一定要大，也可以是個人或小團隊組成的「自軟體開發者」 [註 2]。
林宜敬說得對，要讓台灣軟體產業具規模化與國際競爭力，唯有做產品（Product），屬於產品導向，專案（Project）居次 [ 註 3]。但企業變化多端，企業軟體很難隨插即用（Plug and Play），免不了要客製。NEO 歷經 20 多年的研發，其 SOA 服務元件已可滿足企業大部分需求，但仍有少部分需要客製。因為客製是組裝 SOA 服務元件，所以非常快速。筆者認為企業軟體若能 80%以上採用標準元件（產品），20%以下採用客製元件（專案），則產品和專案兼具，也許是更好的策略。在 POC 階段軟體公司先展示標準模組和產業別模組給企業看，找出必須客製的前端程式。需要客製化的前端程式可分成「必須有」（Must Have）和「最好有」（Nice To Have），判斷上線前「必須有」的客製若低於所有要上線前端程式的 20% 則可立即簽約上線；若發現「必須有」的客製超過 20% 且無現成的 SOA 服務元件可用，則要小心，因為系統能否成功上線就決定於這 20%。只要不缺元件，前端應用程式的商務流程（BP）和使用者介面（UI），AI Agent 都可以快速客製出來。
期望未來台灣的企業軟體也能和硬體一樣，元件、模組、系統都可以由不同的公司生產，經由軟體供應鏈提供給客戶。
二、服務策略：單一模組、逐步導入
軟體公司服務企業的目的是要改善企業的資訊系統，滿足企業的資訊需求。沒有 IT 人員的中小企業組織小、員工不多，可能尚未電腦化，則可以全模組導入以 SOA 服務元件開發的 ERP 系統，例如 NEO ERP。因為客製化的速度很快，所以可以先客製極少數「必須有」的應用，很快上線後再客製其他的應用，而且可依循需求的變化持續客製。
中大型企業都已經有 ERP 系統，並由其 IT 部門維護中。中大型企業更換 ERP 系統的理由可能是原系統太老舊、資料架構不佳、部分功能不符合需求、以及無法整合其他系統的資料。若因功能不符所需或無法整合其他系統資料，企業可以導入以 SOA 服務元件開發的 NEO ERP 應用程式部分模組，不需要換掉整個 ERP 系統。原系統太老舊或底層資料架構不佳必須全套更換，仍可一次一模組更換，將相關資料同步到 NEO 的 EUDA，一個模組上線後再導入下一個模組。不管是部分導入或全套換成 NEO，應盡量模仿原系統的 UI 和 BP 客製前端應用程式，不知不覺把底層架構換掉，讓使用者不必改變太多操作習慣，以免造成組織太大的動盪。
例如原 ERP 系統的製造功能不足，則可繼續在原系統執行採購、銷售和其他功能，只在 NEO 執行製造功能。企業可以先導入 NEO 的核心模組（UC_CORE），定期同步原 ERP 系統和 EUDA 的品項、倉庫、架位等主資料（Master Data），接下來再導入庫存模組（UC_INV）。使用者在原系統執行完採購入庫和銷售出庫等交易後，程式自動呼叫 NEO 庫存模組的「非計劃入庫單」和「非計劃出庫單」服務，並直接轉單至結案，此時 NEO 和原系統的庫存資料即可同步。接下來再導入製造模組（UC_MFG），使用者在 NEO 製造模組執行「工令領料單」，領出材料時自動執行原系統的出庫作業；使用者執行 NEO 製造模組的「工令入庫單」，入庫時自動執行原系統的入庫作業。以上是「單一模組、逐步導入」的一個例子。若原系統較老舊無 API 可用來自動執行入出庫，則可從 NEO 匯出工令的入出庫資料再匯入原系統調整庫存量，以保持 NEO 和原系統的庫存資料同步。
每個應用系統模組的導入都需經過作業分析、系統客製、教育訓練、系統上線 4 個階段。
1. 作業分析：了解關鍵使用者的需求，找到相關的 NEO 應用程式模組，展示給關鍵使用者，關鍵使用者提出客製需求。
2. 系統客製：針對關鍵使用者提出的「必須有」客製需求，調整應用程式模組的使用者介面（UI）和流程（BP），直到使用者接受。
3. 教育訓練：教育訓練全體使用者操作新流程，讓大家了解流程改善後的作法。
4. 系統上線：同步相關主資料、交易資料、和水位資料，全體使用者開始操作新的應用程式模組。
在「作業分析」階段，軟體公司若發現客戶提出的「必須有」之客製不合理，則應該說服客戶使用標準模組的作法，不要輕易進入「系統客製」階段。若客戶連 MRP、ROP、ABC 成本制、…等基本觀念都不清楚，則應先為客戶上課，再來討論客製內容。
導入大型企業應用系統非常的費時費工，時間一拖長，參與的員工可能會失去動力，導致上線失敗，所以系統上線一定要「越快越好」（As Soon As Possible, ASAP）。為了 ASAP，應該採用「單一模組、逐步導入」的策略。
企業日常就應該鼓勵員工提出工作改善建議，而工作改善通常和應用系統有關。企業應該排出與改善事項有關的待上線應用程式模組順序，並逐一導入。先導入一模組（m），經過分析、客製、訓練、上線，再導入下一個模組（m+1），形成一個持續改善的循環，如圖 3。ERP 系統有二個環境：開發環境和營運環境，系統客製階段先在開發環境進行規格、編程、測試，然後把客製程式整合、佈署到營運環境，一次一模組，稱為持續整合／持續部署（Continuous Integration／Deployment, CI／CD）。
「單一模組、逐步導入」的策略讓每個模組能共享資料，但彼此獨立，不會互相干擾，能縮短 ERP 這類大型系統的導入時間，也能兼顧使用者的需求，讓使用者操作以 SOA 服務元件組成的新系統時有更好的使用者體驗（User Experience, UX），可提高導入複雜企業軟體的成功率。
三、系統間的資料同步
「單一模組、逐步導入」的策略主張企業可同時使用新舊系統，但一種交易只會在其中一個系統執行，而系統間的水位資料必須同步。這些資料同步程式可由企業 IT 部門或軟體公司利用 NEO SOA 服務元件來開發、維護。相關的主資料在 NEO 維護後再同步到舊系統，交易資料（例如入庫單、出庫單、會計分錄）會改變水位資料（如庫存、會計科目餘額），在一個系統執行完交易後就必須在另一個系統自動同步相關水位資料。
資料同步程式可以利用 NEO 的「庫存交易歷程查詢」服務，和「傳票總帳日計查詢」服務，取得各產品庫存和各會計科目當日異動的資料，同步各系統的水位資料。
開發資料同步程式之前必須先對應（Mapping）新系統（NEO）和舊系統的資料架構（Data Schema），只要匯入 NEO 和舊系統資料架構文件，AI 就能以 NEO 的 EUDA 為目標架構（Target Schema）找到對應關係，並生成資料同步程式。
企業導入任何像 ERP 這種大型應用系統時，可利用 NEO 的服務元件開發新舊系統的資料同步程式，如圖 4。一次導入一個模組，不要翻天覆地的導入全套大型系統。先導入核心主資料模組，主資料在 NEO 維護，再由 NEO 自動維護舊系統的主資料。導入過程中，使用者先操作舊系統，每期（天或週）的結案交易資料同步到 NEO 並自動執行到結案，盤點新舊系統的水位資料確定資料正確。資料正確後再執行新系統的交易功能並同步舊系統的水位資料。一次只操作一個系統，不像傳統系統導入的平行作業使用者必須同時操作兩套系統。不論交易在哪一套系統執行，NEO 都有該導入模組的完整交易資料和水位資料。導入大型系統必須能在短時間內看到新系統的成效，專案才不會冷掉。一次導入一模組，專案成功的機率較高。
[ 瀏覽葉宏謨所有專欄文章 ]
多年前在孫運璿和李國鼎等前輩的努力下，台灣有了很好的資訊硬體基礎建設（Infrastructure），造就了今天傲視全球的資訊硬體供應鏈。但是，像 SAP 或 Oracle 這種企業應用軟體，台灣至今完全站不上世界舞台。企業應用系統不像電腦、家電、汽車，買來就能用，會有繁瑣的導入及客製服務。如果以 NEO 作為企業應用軟體的基礎建設，外掛在 SAP、Oracle 或其他 ERP 系統旁邊，利用 AI 同步資料，讓各資服軟體公司或自軟體開發者 [ 註 2]，都能組裝元件作成應用程式、組裝應用程式作成模組、再組裝成系統，逐步改善原來的 ERP 系統，像螞蟻雄兵一樣形成一條軟體供應鏈，台灣的軟體必能像硬體那樣外銷到全世界。
四、結論
每個企業的需求都不一樣，利用 NEO 的 SOA 服務元件可開發各種前端應用程式，包括標準模組、產業別模組、和個別企業的客製化模組，這些應用程式模組構成了個別企業的專屬應用系統，這是企業軟體的「系統模組化、模組元件化」產品策略。企業導入大型應用系統時不要全模組一次導入，可利用 NEO 的 SOA 服務元件和 EUDA 作為中介，同步新舊系統的相關資料，一次導入一個模組。待上線的模組越來越少，已上線的模組越來越多，最後全部換成基於 NEO 的新模組。這是企業應用軟體的「單一模組、逐步導入」的服務策略。開發元件、模組、系統的軟體公司或自軟體開發者形成台灣的軟體供應鏈，台灣的軟體就能行銷全世界。
參考文獻
[ 註 1] 葉宏謨，資料主權，CIO Taiwan 專欄，2025 年 12 月。
[ 註 2] 葉宏謨，自媒體與自軟體，CIO Taiwan，2026 年 6 月 7 日。
[ 註 3] 林振輝、施鑫澤採訪，從晶片到伺服器打造 AI 硬體強權之路，CIO 雜誌，2025 年 11 月，P.44-47。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
