套裝軟體或客製系統，怎麼判斷適不適合？先找出不能妥協的流程

「套裝軟體比較便宜，客製系統比較符合需求」這句話聽起來合理，卻不夠拿來做決定。

真正要比較的不是功能表有幾格打勾，而是你的主要流程有多少可以跟著產品走、多少一定不能改，以及資料、整合與日後維護要由誰承擔。

如果這些問題還沒釐清，套裝方案可能買回來才發現核心流程塞不進去；客製方案也可能把原本可以直接採用的標準功能重新做一遍。比較實際的做法，是先完成五項盤點，再決定套裝、客製或混合式。

一、先看核心流程有多標準

先挑一條每天真的會跑的主要流程，從開始條件一路寫到完成結果。例如：客戶詢價、報價核准、成立訂單、出貨、對帳。

接著把每一步分成兩類：

• 可以配合系統調整的做法；
• 因法規、合約、風險控制或商業差異而不能妥協的做法。

如果主要流程與同業常見做法接近，而且團隊願意調整作業方式，套裝產品通常值得先試。若流程本身就是公司的競爭方式，或有特殊核准、計價、履約與權限邏輯，客製或混合式才更有比較價值。

「大家一直這樣做」不等於不能改；「畫面想長得不一樣」也不等於需要客製。不能妥協的理由應該能連回營運結果、風險或外部義務。

二、分清楚設定、擴充與改程式

套裝產品常說可以客製，但「客製」可能只是欄位、表單、角色、通知或流程節點的設定，也可能需要外掛、API，甚至由原廠另外開發。

評估時不要只問「做不做得到」，而要逐項問：

• 後台設定就能完成嗎？
• 版本更新後設定會保留嗎？
• 需要額外模組、授權或顧問服務嗎？
• 必須串 API、寫外掛，還是改產品核心？
• 由誰測試、上線與處理更新後的相容問題？

如果核心需求只能靠大量繞路、人工補表或高風險外掛完成，功能清單看似符合，實際流程仍可能不適合。

三、把整合與資料帶得走列為正式條件

系統很少單獨存在。它可能要接會計、付款、電商、倉儲、會員、簡訊、身分驗證或既有資料庫。

因此，套裝與客製都要回答：

官方技術指引反覆強調資料控制、開放標準與避免供應商鎖定。對企業來說，重點不是完全沒有依賴，而是事前知道依賴在哪裡、退出時拿得回什麼。

四、看需求變動發生在哪一層

需求常改，不代表一定要客製。

如果變動多半是欄位、通知內容、報表條件或角色設定，套裝產品的可設定能力可能已足夠。若變動集中在核心決策規則、跨系統流程、即時計價或特定客戶合約，產品每次更新都要等待供應商排程，客製控制權的重要性才會提高。

反過來說，流程還在每週推翻、主要使用者也說不清完成條件時，直接客製可能只是把未定案的流程寫進程式。此時先用短期工具、原型或有限範圍試行，通常比一次做完整系統更容易看清問題。

五、比較長期責任，不只比較第一張報價

套裝軟體不只看訂閱費；客製系統也不只看開發費。兩邊都要把導入、資料整理、設定、整合、教育訓練、權限管理、更新、備份、監控、資安修補與退出成本列入。

套裝產品由供應商維護核心版本，但企業仍需管理帳號、設定、資料品質、整合與使用流程。客製系統能控制更多細節，但產品決策、技術維護、測試與版本升級的責任也不會消失。

因此，應比較的是「誰負責什麼、出問題怎麼處理」，而不是只比較誰的第一年價格較低。

三種結果都可能合理

適合優先試套裝

主要流程成熟且常見、團隊能配合產品調整、必要設定已覆蓋、整合介面足夠，而且供應商的資料匯出與維護方式可接受。

適合評估客製

不能妥協的流程正是營運核心，規則與權限有明確差異，資料及多系統整合需要較深控制，而且組織願意承擔產品與維運責任。

適合混合式

會計、付款、身分驗證等成熟能力採既有產品；把真正有差異的流程做成獨立模組，再透過明確介面整合。混合式不是折衷失敗，而是避免把每個功能都當成同一種問題。

若評估後走向客製或混合式，奧微軟體的系統開發服務涵蓋內部管理系統、後台、資料庫、權限控管與流程整合。

明示虛構教學例：批發訂單流程

以下是完全虛構的教學情境，不是客戶案例。

假設一家批發商需要客戶資料、商品、庫存、訂單、出貨與發票。這些基礎能力在許多套裝產品中都有，團隊也願意調整一般作業流程。

但公司另有一段不能妥協的規則：同一商品會依客戶合約、交貨地、累計數量與有效期間套用不同條件，報價變更還要經過特定層級核准，並留下可追溯原因。

這時不必直接在「整套套裝」與「全部重做」之間二選一。可以先驗證套裝產品是否能穩定處理商品、庫存、訂單與發票，再把特殊報價與核准規則列成獨立模組，確認雙方資料、失敗補償與責任邊界。

如果實測後發現套裝設定就能可靠處理特殊規則，便不需要為了「看起來比較專屬」而另做系統。若只能靠大量人工備註與試算表補洞，才有理由把該段流程拉出來評估客製。

反例：不是流程重要就一定要自己做

薪資、會計、電子發票或法規更新頻繁的標準能力，即使非常重要，也不代表自行客製就是較好的選擇。若組織沒有持續追蹤規則、測試更新與維護系統的能力，採用有清楚責任與更新機制的成熟產品，可能更符合實際風險。

同樣地，套裝產品有很多功能也不表示適合。若核心流程必須長期繞路、資料不能完整匯出、關鍵整合缺乏穩定介面，功能數量無法補回控制權。

帶著這一頁再去比較

在看 Demo 或詢價前，先整理一頁：

1. 一條主要流程與完成條件；
2. 三到五個不能妥協的規則及理由；
3. 必接系統與資料進出方式；
4. 預期會變動的規則；
5. 導入、維運、資安與退出的責任人。

這一頁能讓不同方案回答同一組問題，也比較容易看出應該買、應該做，還是只客製真正有差異的部分。

若你正在套裝與客製之間評估，可以先把上述五項整理成同一份盤點，再帶著實際流程討論。奧微軟體可依已確認的需求與系統邊界協助釐清技術方案；是否適合承作、範圍、時程與費用仍須另行評估。

資料來源與核對日期

• GOV.UK Service Manual, Choosing technology: an introduction，核對日期：2026-09-18。
• GOV.UK Service Standard, Choose the right tools and technology，核對日期：2026-09-18。
• GOV.UK Service Manual, Using commercial-off-the-shelf products and services，核對日期：2026-09-18。
• GOV.UK Service Manual, Managing software dependencies，核對日期：2026-09-18。
• GOV.UK Service Manual, Working with open standards，核對日期：2026-09-18。

作者：奧微軟體內容團隊。本文為一般軟體需求與技術路線整理；奧微軟體開發企業社與軟體開發服務有商業關係，本文不構成特定產品採購、系統選型、法規遵循、資安、時程、費用或成果承諾。