公司流程還在用 Excel 管，什麼時候該做系統？

文章導讀

截至 2026 年，公司流程還在用 Excel 管的中小企業仍然非常常見，而什麼時候該做系統，也就成了每年都會被拿出來問一次的問題。試算表便宜、彈性大、每個人都會用，公司剛起步時幾乎是最有效率的選擇。真正需要判斷的不是「Excel 好不好」，而是你的流程有沒有走到某個門檻：檔案開始互相參照、有人專門在對帳、每次月結都要花兩天把資料兜起來。這篇要拆解的就是那個門檻長什麼樣子，以及跨過去之後該用什麼順序換成系統。

Excel 沒有錯，錯的是讓它承擔整條流程

先講結論：Excel 是很好的記錄工具與運算工具，但它不是為了「多人同時執行一條有先後順序的流程」而設計的。一旦你的流程需要交接、需要留痕、需要在某個條件成立時通知下一個人，它就開始超出自己的守備範圍。

這個轉折不是某一天發生的，而是慢慢累積：一開始只有一份訂單表，後來多了一份庫存表要對照，接著業務各自維護自己的客戶清單，最後出現一份「彙總用」的主檔，由某位同事每週手動貼上。當公司開始需要一個人專職維護試算表本身，這件事就已經變成流程了。

• 常見誤解

  等公司規模夠大再說

  把導入系統想成規模的獎賞，覺得員工人數還不到就不必考慮。但撐不住的原因是流程的複雜度，不是人數。舉例來說，一間十來人的公司如果有好幾條流程互相牽連，可能比一間三十人但各部門各做各的公司更早撞牆。

• 實際情況

  看的是資料被重複輸入幾次

  同一筆訂單在報價表、出貨表、請款表各輸入一次，就有三個地方可能出錯，而且錯了以後還要回頭比對是哪一份先錯。這件事跟公司大小無關，是流程結構決定的。

另一個容易混淆的地方是「檔案很多」不等於「該做系統」。很多公司的試算表雖然散，但彼此不相關，各部門用得很順，硬要整合反而是製造工作。真正的判準是這些檔案之間有沒有依賴關係，也就是改了 A 就必須跟著改 B。

六個該認真評估換系統的訊號

這六個訊號的共同點是：問題已經從「這份檔案不好用」變成「這件事需要有人天天處理」。不需要六個同時出現，通常兩到三個就值得評估。

訊號	你在公司裡會看到的樣子	為什麼試算表撐不住
同一筆資料重複輸入	報價、出貨、請款各打一次，還要人工核對	沒有單一來源，錯了要回頭找是哪一份先錯
版本開始分歧	檔名出現最終版、最新版、確認版	檔案在信件與訊息之間來回傳遞，兩個人各改一份就會互相覆蓋；即使改用雲端試算表共編，也難以規定哪些欄位不能改、誰有權改
有人專職在整理表格	每週固定花半天到一天做彙總	這段時間本身就是人力成本，且無法累積
權責交接靠口頭或訊息	下一步要誰做，靠群組提醒或當面講	沒有狀態欄位，事情漏掉時沒人發現
對外的資料需要即時	客戶或業務想查進度，得回頭問內勤	共用的單位是整份檔案，沒辦法讓每個客戶只看到自己那一筆，也沒有誰查過什麼的紀錄
報表要拼很久才生得出來	月結或季報要花數天彙整	資料格式不一致，每次都得重新清理

這六項不是檢查表，而是判斷方向。實務上通常是其中一項先痛，才會帶出其他幾項。

第四項與第五項代表流程已經跨出公司內部，開始牽涉到客戶體驗，通常也是老闆最有感的階段。如果你的需求已經走到「外部的人要能自己查、自己填、自己下單」，那要處理的其實是一個網站等級的專案，可以先看看客製化功能案例裡的做法，會比較容易對照自己的情境。

用 Excel 管流程的成本，藏在三個地方

Excel 的成本集中在三個地方：核對、重工與等待，三者都不會出現在帳上。

Excel 的授權費用是明碼標價的，多數公司也早就付了，所以很容易覺得用它管流程等於不花錢。真正的成本不在授權，而在使用過程中被分散吸收掉，帳上永遠看不到。

• 核對成本

  兩份以上的檔案只要有交集，就必然需要有人比對。這段工作不產生任何新價值，卻會隨著資料量與檔案數一起變多，檔案愈多、要比對的組合就愈多。這件事通常會落在某一位資深同事身上，這個人一旦請假或離職，流程就會慢下來。

• 重工與補救成本

  一個貼錯欄位的動作，可能造成出貨數量錯誤、報價金額錯誤或庫存帳不符。修正一次要先找出錯在哪一份、再回頭改所有受影響的表，花的時間通常遠多於當初輸入，而且往往發生在最忙的時候。

• 等待成本

  檔案被鎖住、同事還沒更新、彙總還沒做完，這些等待不會被記在任何地方，但它讓決策延後。老闆想知道這個月賣得怎麼樣，答案要等兩天，這兩天的判斷就是憑感覺做的。

什麼情況你現在還不需要做系統

直接說：不是每個流程都該被系統化，有些情況現在動反而是浪費。

• 這條流程的規則還在頻繁變動嗎？（規則沒定型就做系統，等於把還會改的東西固化下來，改一次就是一次工程）
• 這條流程從頭到尾是不是只有一到兩位同事在跑？（注意這裡看的是單一流程的使用人數，不是公司總人數；單人作業的試算表效率很高，多數時候不需要額外的介面與權限設計）
• 資料量會不會在可預見的一年內明顯成長？（如果量體穩定、也沒有對外開放的需求，維持現狀是合理的）
• 現在的痛點是流程本身，還是根本沒有標準流程？（沒有標準流程時，先把流程講定，比先找工具重要得多）

還有一種情況是流程本身很標準，訂單、進銷存、報價都跟同業差不多，這時候先評估市面上現成的套裝軟體或訂閱制工具通常比較划算。客製開發真正要處理的，是那些現成工具做不到、又跟公司做生意的方式綁在一起的部分。

最後一項最常被忽略。系統會忠實反映你給它的流程，如果流程本身是混亂的，做出來的東西只會是一個更難改的混亂版本。導入卡住的時候，問題常常不在技術，而在需求盤點階段沒把事情講清楚，這一點在網站專案的合作流程裡也是同樣的道理。

系統的複雜度是往上疊的，這是最常被低估的一件事

系統要處理的不是欄位，而是欄位之間的關係、狀態之間的轉換，以及所有例外情況，所以複雜度是往上疊的。把流程搬進系統，看起來像把試算表的欄位換個地方放，實際上不是。試算表允許例外，系統不允許例外沒有被定義，這就是複雜度的來源。

舉個例子。一張訂單在試算表裡只是一列，但在系統裡它有狀態：待確認、已確認、部分出貨、已出貨、已請款、已退貨。每一個狀態轉換都要決定誰能改、改了之後庫存怎麼動、能不能回到上一步。原本一列資料，變成一組規則。

再加上折扣、贈品、換貨、跨期結算這些天天在做的事，規則之間就會開始互相影響。這時候要煩惱的已經不是「功能做不做得出來」，而是每加一條規則，就要重新驗證它跟既有規則有沒有衝突。這件事沒有捷徑，只能靠有人持續看著。

• 常見誤解

  功能做完就等於系統做好了

  把導入想成一次性的建置：規格談完、做出來、上線就結束。但流程會變、法規會變、合作對象的格式也會變，系統跟著要調整，這是常態不是意外。

• 實際情況

  系統是要持續被照顧的資產

  上線只是起點。後面還有版本更新、資料備份、資安處置，以及每次規則變動帶來的調整，這是需要有分工的團隊長期處理的事。

導入順序：系統要從哪一段流程開始換

從規則最穩定、又最耗人力的那一段開始，通常是訂單建檔、報價產出或庫存異動。最常見的錯誤是從最複雜、最有爭議的那段開始，結果卡在需求討論裡出不來，全公司對系統化這件事失去信心。

• 先把現況畫出來

  用最土的方法就好：一條流程從哪裡開始、經過幾個人、每個人做什麼、資料存在哪。這一步通常由熟悉流程的同仁與規劃方一起做，畫完就會直接看到重複與斷點在哪裡。

• 挑規則穩定、耗時最多的那一段先動

  規則穩定代表做出來不會馬上要改，耗時最多代表效益立刻看得到。訂單建檔、報價產出、庫存異動通常落在這一類，而還在頻繁調整的行銷活動規則就先不要碰。

• 確認資料的單一來源

  在動手之前先決定：客戶資料以哪裡為準、商品資料以哪裡為準。這個決定沒做，後面每個環節都會出現兩份互相矛盾的資料，補救的成本比一開始講定高得多。

• 保留一段新舊並行的期間

  不要在某個月的第一天全面切換。讓關鍵流程在系統與原本的做法上並行一段時間，一方面驗證正確性，一方面讓同仁習慣新的操作。這段期間的工作量會暫時增加，屬於導入的正常成本，排時程時就要一併算進去。

• 再往外擴到對外的環節

  內部流程站穩之後，才處理客戶查詢、線上下單、會員這些對外的部分。順序反過來做，等於在還沒穩定的基礎上直接面對客戶。

如果下一步是把流程往外開放給客戶使用，要規劃的其實是一個線上的營運入口，形態可能是電商購物車案例那種交易型網站，也可能是線上課程案例那樣的會員型架構。兩者背後的資料模型不同，愈早釐清愈好。

系統上線之後，真正的成本才開始計算

先給答案：導入的建置費用是按段落發生的，做一段付一段；但系統的持有成本是上線之後每年都在的。評估時只看第一段的建置報價，等於只算了買車的錢，沒算油錢與保養。

持有成本大致落在三塊：環境與維運、功能調整、以及資料本身的管理。環境與維運包含主機、更新、備份與資安處置（這幾項各自是什麼，見網站的組成與名詞對照），這一層由維護方統一負責執行，理由是更新要排程、備份要驗證、遇到異常要能當下處理，權限分散反而會拖慢應變。公司端保有日常營運需要的操作，出貨、查單、上稿、調整內容都不受影響。

成本項目	性質	什麼時候會被觸發
環境與維運	固定，逐年發生	持續進行，含更新、備份與資安處置
功能調整	變動，視需求而定	流程改變、法規更新、合作對象格式異動
資料管理	隨資料量成長	資料累積、報表需求增加、歷史資料歸檔
教育訓練	階段性	上線初期與人員異動時

這四塊在評估階段就一併看，才不會出現「第一段建置很便宜、但第二年開始超出預算」的狀況。

另外一件值得在合作開始前就講清楚的，是資料與開發成果的分野。公司的營運資料，例如訂單、客戶與內容，屬於公司，收尾時本來就會提供。而為專案開發的功能模組與客製前端，多數情況屬於開發方的著作權，以授權方式供這個系統使用。這是軟體產業的通用觀念，因為同一套元件會用在多個專案上，可重複使用正是它的價值。公司若需要完整取得這部分的權利，一般是另以買斷計價，並且在合作開始前談定。

想理解各種角色分別負責哪一段，可以參考我們寫過的官網維護需要哪些角色，裡面的分工邏輯同樣適用於系統的長期維運。

把 Excel 流程換成系統，先從釐清現況開始

快找整合顧問的網站架設與主機代管，處理的正是這一段：把既有流程盤清楚、決定哪一段先做、變成可以長期運作的系統，並在上線之後持續負責環境維運與後續調整。企劃、設計、工程與系統維運分別由不同的人負責，流程盤點與後續調整不會因為單一窗口的排程而停下來。

如果你現在還在判斷「到底該不該做」，也不必急著決定。可以先看服務項目了解我們負責的範圍，或直接把目前的流程現況告訴我們，我們會先幫你判斷這件事是不是現在該做。

內文精華總結

• 判準不是規模：該不該換系統，看的是同一筆資料被重複輸入幾次、檔案之間有沒有依賴關係，不是員工人數或營業額。
• 六個訊號：重複輸入、版本分歧、有人專職整理表格、交接靠口頭、對外資料需要即時、報表拼很久，出現兩到三項就值得評估。
• 成本藏在三處：核對、重工與等待都不會出現在帳上，但會隨資料量與檔案數放大，且往往集中在某一位資深同事身上。
• 不是每個流程都該做：規則還在頻繁變動、單一流程只有一兩人在跑、或還沒有標準流程時，現在動反而是浪費；流程夠標準時，先看現成工具通常更划算。
• 複雜度是乘法：試算表允許例外，系統不允許例外沒有被定義；每加一條規則都要重新驗證與既有規則的衝突。
• 順序與長期成本：先動規則穩定又耗人力的那一段、保留新舊並行期；評估時把環境維運、功能調整、資料管理與教育訓練一起算進去。

延伸閱讀

• 官網維護需要哪些角色
• 網站專案的合作流程
• 客製化功能案例
• 網站作品實例

重點整理