度身訂造系統香港：取代 Excel 的範圍、資料模型與權限實戰

創業初期，Excel 是好朋友：開一個檔案，加幾個欄位，馬上可以用。但當客戶由幾十個變成幾百個、同事由兩個變成十幾個，同一套 Excel 就會變成日常運作的風險來源——版本對不上、公式被覆蓋、手機看不到、離職同事的密碼鎖住了關鍵資料。本文不是單純叫你把 Excel 換成系統，而是講清楚：何時真的需要度身訂造系統、範圍與資料模型怎樣定、權限與維護怎樣安排，以及為何「先做需求分析」比「先問價錢」更省錢。

以下內容由 ADWire Agency 團隊整理，結合香港本地情況與可查證的公開資料。

一、Excel 由幫手變成風險的三個臨界點

Excel 本身沒問題，問題是它被用來做一件它不擅長的事：讓多個人同時、安全地維護同一份不斷更新的資料。以下三個臨界點，通常就是企業開始考慮系統與 Excel 的分界。

臨界點一：同時維護同一份資料的人超過兩個

只要多於一個人會改同一份表，就會出現「哪個版本最新」的問題。有人在自己電腦改了、有人用電郵傳來傳去、有人加了新欄位而另一個人不知道，結果每個人都以為自己的版本才是對的。這類問題的根源不是同事不小心，而是工具本身沒有讓「只有一份正確資料」變成必然。

臨界點二：公式與權限混合在一起

Excel 的公式和資料放在同一格，任何有編輯權的人都可以順手改動一條公式，而其他人未必察覺。當報價、佣金或庫存靠這些公式計算時，一次無意的覆蓋就可能導致錯價或錯數。更麻煩的是，Excel 很難做到「這個人只能看、不能改」這種細緻的權限劃分。

臨界點三：流程依賴某位同事的記憶

當流程只存在於某位資深同事的腦袋裡——例如「先核對這個、再通知那個、然後才開發票」——一旦他放假或離職，接手的人就要從頭摸索。這種「隱性知識」是中小企最容易被低估的風險之一。系統化的價值，正是把流程由個人記憶變成可交接的步驟。

二、度身訂造系統是什麼，又不是什麼

度身訂造系統，是指按你公司實際的流程與資料結構，開發一套專屬的管理軟件。它與現成 SaaS 最大的分別，在於「誰去遷就誰」：SaaS 要求你遷就它既有的功能與流程，訂造系統則按你的流程去設計。

但它不是萬能，也不是所有公司都需要。如果一個流程在市場上已有成熟、標準的做法（例如基本會計、電郵營銷），用現成 SaaS 通常會比訂造更快、更便宜、維護責任也由供應商承擔。訂造的合理理由，是「流程本身有特殊性，市面工具覆蓋不到」，而不是「想有一個屬於自己的系統」。

三、何時應該訂造？何時用現成 SaaS 就夠

表格為本文按常見情況歸納的判斷框架，非官方標準。可參考 Gartner 的 Build, Buy or Ally 取捨框架（Gartner）。

四、決定成敗的兩件事：範圍與資料模型

訂造系統超支或失敗，多數不是因為技術做不到，而是因為這兩件事沒在一開始講清楚。

範圍：第一版只做什麼

範圍（Scope）定義的是「第一版要做哪些功能、不做哪些功能」。最常見的失誤，是把所有部門的所有願望一次過寫進需求，結果開發期無限延長、上線一再延後。較穩健的做法是先做一個核心流程（例如由報價到開單），讓它真正可用、可量度，再按實際回饋擴展。範圍一旦寫定，任何新增功能都應該被視為下一階段，而不是免費追加。

資料模型：欄位與關係怎樣定

資料模型決定「資料怎樣儲存與關聯」。例如一個「客戶」應該有哪些欄位、一個客戶可以有多少張報價、報價與訂單之間怎樣連結。這部分一旦出錯，日後改動的代價會很大，因為所有功能都建立在它之上。實務上，應在開發前用一兩頁清楚列明主要實體（客戶、產品、訂單、發票）與它們的關係，並確認中文字元、多幣種、日期格式等本地細節都處理得到。

五、權限、資料安全與記錄保存

最低權限與角色劃分

系統應做到「每個人只看到、只改到他需要處理的部分」。銷售未必需要看到成本價，客服未必需要看到完整財務紀錄。最低權限原則除了保障資料，也降低了誤操作的機會。設計時應同時考慮：誰可以新增、誰可以修改、誰只能檢視、離職時如何即時停用帳號。

資料匯出與紀錄保存

兩件事必須在合約中講清楚。第一是資料匯出：系統應能將資料匯出為通用格式（如 CSV），避免日後更換供應商時被鎖死。第二是紀錄保存：《稅務條例》第 51C 條要求業務的收支記錄以英文或中文保存不少於 7 年，《公司條例》（第 622 章）第 373 條亦要求公司保存會計記錄。若系統涉及報價、訂單或收款紀錄，其保存期限與可匯出性就必須納入設計。

個人資料的處理

若系統會儲存客戶或員工的個人資料，就受《個人資料（私隱）條例》（PDPO）的六項保護原則規管，包括收集目的、使用限制、保安與保留期限。實務上應避免收集不必要的資料、限制內部存取、並在資料不再需要時刪除。把客戶名單匯入系統用作日後推廣時，亦要符合直接促銷的相關規定。

來源：稅務局：業務記錄保存規定、電子版香港法例：第 622 章第 373 條、PCPD：個人資料（私隱）條例概覽，查核日期 2026年10月3日。

六、開發與交付：分階段驗收與原始碼歸屬

一個較不容易出事的交付方式，是把專案切成幾個可見成果的階段：先做需求規格、再做核心功能、然後試用與修正、最後上線與交接。每個階段都應有明確的驗收標準，讓你可以在中途就發現方向偏差，而不是等到最後一刻。

另外兩件事要在合約寫清楚：原始碼與帳戶的歸屬。訂造開發的原始碼及你付費購買的帳戶，應歸客戶所有，交付時一併移交；第三方平台（雲端主機、短訊或電郵服務）的帳戶建議以客戶名義開立，避免日後更換供應商時出現交接困難。同時應要求提供操作說明及必要技術文件，方便你的團隊或日後的供應商接手。

七、成本與維護：為何要先做需求分析

度身訂造系統並無一個公開的標準價目表——就像買樓不會有「一間屋多少錢」的通用答案。成本主要取決於三件事：第一版的範圍有多大、需要整合幾個現有系統、以及舊資料需要清理到什麼程度。因此較務實的做法是先做一次需求分析（Discovery），把範圍、流程與資料狀況梳理清楚，再提供明確的報價與時間表。沒有經過這一步就報出的價，多數會在開發中途因「追加需求」而變動。

另一個常被低估的項目是長期維護。系統上線後仍需要處理使用者回饋、系統更新帶來的相容問題、以及業務變化引致的流程調整。這部分應在報價階段一併問清楚：維護範圍包括什麼、回應時間多長、按什麼方式計費。若沒有預留維護資源，系統很可能在幾個月後慢慢被棄用，回到 Excel。

八、香港中小企的規模背景

把以上判斷放進香港的企業結構，會更清楚為何中小企需要一套量化的方法。截至 2026 年 6 月，香港約有 36 萬家中小企業，佔本港企業總數 98% 以上，合共為約 120 萬人提供就業機會。大部分本地企業的規模，都適合由「一個最花時間的工序」開始系統化，而不是一次過改動整個運作。

來源：工貿署中小企業支援與諮詢中心，查核日期 2026年10月3日。

九、常見問題 FAQ

十、總結：先定義問題，再決定要不要訂造

回到最初的問題：Excel 何時應該換成系統？答案不是按公司規模或檔案大小，而是按「這個工序一年吃掉多少成本、以及它是否可以被可靠地標準化」。先量化，再判斷；流程可以用成熟 SaaS 處理的，就用 SaaS；只有真正獨特、市面工具覆蓋不到的流程，才值得訂造。

如果你正在處理的是資料散落、多人之間版本衝突、或流程依賴個人記憶的問題，可先了解我們的 企業系統與 App 開發服務，我們會先協助你界定範圍與資料模型，再決定最合適的做法。