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

文章導讀

很多老闆以為，系統是公司大到一個程度才需要的東西。這個想法很自然：試算表便宜、彈性大、每個人都會用，公司剛起步時，它幾乎是最有效率的選擇。可是 Excel 撐不住的那一刻，跟公司大小關係不大。它來自流程走到了某個門檻。檔案開始互相參照，有人專門在對帳，每次月結都要花兩天把資料兜起來。這篇要拆的，就是那個門檻長什麼樣子，以及跨過去之後，該用什麼順序換成系統。

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

先講結論：Excel 是很好的記錄與運算工具，但它的設計，沒有考慮「多人同時跑一條有先後順序的流程」。流程一旦需要在同事之間轉手、需要留下紀錄，Excel 就開始吃力。要在某個條件成立時通知下一個人，更超出它的守備範圍。

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

• 常見誤解

  等公司規模夠大再說

  覺得員工人數還不到，就不必考慮。可是一間十來人的公司，如果有好幾條流程互相牽連，可能比一間三十人、各部門各做各的公司更早撞牆。

• 實際情況

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

  同一筆訂單在報價表、出貨表、請款表各輸入一次，就有三個地方可能出錯。錯了以後，還要回頭比對是哪一份先錯。

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

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

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

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

這六項是判斷的方向，不必逐一打勾。實務上，通常是其中一項先痛，才帶出其他幾項。

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

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

Excel 的成本，集中在三個地方：核對、重工與等待。

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

• 核對成本

  兩份以上的檔案只要有交集，就需要有人比對。這段工作不產生新價值，檔案愈多，要比對的組合就愈多。它通常落在某一位資深同事身上，這個人一請假或離職，流程就慢下來。

• 重工與補救成本

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

• 等待成本

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

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

直接說：有些流程現在還不該動，動了反而是浪費。

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

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

清單的最後一項最常被忽略。系統會忠實反映你給它的流程；流程本身是混亂的，做出來的，只會是一個更難改的混亂版本。導入卡住的時候，最常見的原因是需求盤點沒講清楚。例外怎麼處理、誰能改什麼，到了開發階段，才發現各部門的說法不一樣。這一點，在網站專案的合作流程裡也是同樣的道理。

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

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

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

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

• 常見誤解

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

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

• 實際情況

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

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

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

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

• 先把現況畫出來

  用最土的方法就好：一條流程從哪裡開始、經過幾個人、每個人做什麼、資料存在哪。這一步，最好請最熟悉流程的同事一起畫。畫完，重複和斷點在哪裡，就很清楚了。

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

  規則穩定，代表做出來不會馬上要改；耗時最多，代表效益立刻看得到。還在頻繁調整的行銷活動規則，就先不要碰。

• 確認資料的單一來源

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

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

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

• 再往外擴到對外的環節

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

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

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

導入的建置費用依專案階段規劃，報價時分段列出；系統的持有成本，則是上線之後每年都在。評估時只看建置報價，等於只算了買車的錢，沒算油錢和保養。

持有成本大致分成四塊。最固定的是環境與維運，包括主機、更新、備份與資安處置（這幾項各自是什麼，見網站的組成與名詞對照）。這一層由維護團隊統一執行。更新要排程、備份要驗證，遇到異常要能當下處理，權限一分散，應變就會變慢。你們公司內部照樣使用日常營運需要的操作，出貨、查單、上稿與內容更新都不受影響。

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

這四塊在評估階段就一併看，才能把第一年的建置與往後每年的持有成本放在同一張表上一起判斷。

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

系統的長期維運牽涉哪幾種專業，可以參考我們寫過的官網維護需要哪些角色。裡面的分工邏輯，同樣適用。

我們怎麼判斷一條流程該不該做成系統

評估這類需求，參考的做法是先拿一份真的在用的試算表來看，最好是那份「彙總用」的主檔。資料去識別化也沒關係，要看的是結構。哪些欄位靠公式、哪些靠手動貼上，哪幾份檔案互相參照，都藏在結構裡。看一份真實的檔案，比聽十分鐘的描述，更快知道流程卡在哪。

也要特別看「備註」那一欄。試算表裡的例外情況，幾乎都寫在那裡，那也是系統最需要先定義清楚的地方。備註欄越長，需求盤點要花的時間就越多。有時候，比較好的第一步，是先把這些例外的處理方式定下來，系統晚一點再做。

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

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

常見問題