內部後台系統開發指南：何時該從試算表走向客製
一開始只是一份訂單試算表。後來加了分頁記庫存，再開個群組通知出貨，月底再花兩天把這些拼成報表。
等到某天發現「有人改了但沒人知道」「同一筆訂單在三個地方數字不一樣」「離職的同事帶走了那份只有他會用的檔案」，問題就已經不是工具，而是流程沒有一個共同的落腳處。
這篇談的是：什麼時候該從試算表或現成 SaaS 走向客製後台、怎麼盤點需求、怎麼選作法，以及怎麼避免做出一套沒人用的系統。
該升級的訊號
不是規模變大就一定要導入系統。真正的訊號是下面這幾種：
一、同一份資料被抄了好幾次。 客戶下單填一次、業務登記一次、出貨單再打一次、財務再輸入一次。每一次複製都是出錯的機會，而且錯了很難追出源頭。
二、流程無法被擋住。 應該要主管核可才能出貨，但實際上只要有人跳過就會跳過，事後才發現。試算表沒辦法設關卡。
三、權限只能靠默契。 所有人都看得到所有資料，包含薪資、成本、客戶聯絡方式。要限制就只能另外開一個檔案，然後兩份檔案開始不一致。
四、報表要靠手工拼。 每個月固定有人花好幾天整理數字，而且整理完的數字沒人能完全保證正確。
五、資料查不到歷史。 想知道這筆訂單為什麼改成這個價格、是誰改的、什麼時候改的——沒有紀錄。
六、系統之間沒有連線。 官網、金流、物流、客服各自為政，中間靠人工搬運。這一項其實是整合問題，處理方式可以看系統整合與 API 串接開發指南。
如果你只中了一兩項，優先處理那一項就好；中了四項以上，通常代表流程已經超過試算表能承載的範圍。
需求盤點的三個面向
後台專案失敗最常見的起點，是需求只寫了「我要一個管理訂單的後台」。要讓這件事可以被估價、被驗收，至少要盤點三個面向。
一、流程
把一筆資料從產生到結束的完整路徑畫出來：誰建立、經過哪些狀態、每個狀態由誰推進、哪些情況要退回、什麼時候算結束。
特別要問的是例外。 正常流程通常很好寫，真正吃掉工時的是例外：取消怎麼辦、部分出貨怎麼辦、退貨後帳要怎麼修、臨時插單的優先權怎麼排。這些在試算表時代是靠人腦處理的，搬進系統就必須明確定義。
二、角色與權限
列出所有會用到系統的角色，逐一回答三個問題：看得到什麼、能改什麼、能核可什麼。
常見的盲點是只想到自己部門。實際上還要考慮：主管的檢視需求、財務的對帳需求、外部協力廠商是否需要有限度的存取、以及離職時權限怎麼收回。權限設計得越晚，改起來越貴，因為它會滲透到每一個畫面。
三、報表
先問「這個數字是要拿來做什麼決定」，再決定報表長什麼樣。很多報表需求其實只是把舊有的手工表格照搬，而那份表格的格式本身可能只是因為當年 Excel 好排。
要確認的事：多久看一次、給誰看、要不要能匯出、口徑怎麼定義（例如業績算下單日還是出貨日、含不含稅、退貨怎麼扣）。口徑沒講清楚，報表做出來一定會被說數字不對。
把這三個面向寫成文件的方法，可以參考軟體需求規格怎麼寫。
套裝、低程式碼、客製：怎麼取捨
| 作法 | 適合什麼 | 主要限制 |
|---|---|---|
| 現成套裝軟體 | 通用管理工作（記帳、薪資、標準進銷存） | 流程要遷就軟體，客製空間有限 |
| 低程式碼平台 | 流程單純、需求會變動、想快速試用 | 複雜邏輯會撞牆，資料與畫面搬遷困難 |
| 客製開發 | 流程就是你的競爭力、需要串接既有系統 | 初期投入高，需要明確需求 |
| 混合 | 通用部分用套裝、關鍵流程客製並串接 | 需要規劃整合與資料一致性 |
判斷的核心問題是：這段流程是不是你和同業不一樣的地方。
記帳、薪資這類工作，全台灣的做法差不多，市面上的成熟軟體便宜又穩定，客製它幾乎沒有道理。反過來說，如果你的接單方式、排程邏輯或計價規則本身就是優勢所在，硬要遷就套裝軟體的固定流程，等於把優勢磨平。
低程式碼平台值得單獨提一句：它很適合用來驗證需求。在投入客製開發之前，先用平台快速做一個能跑的版本，讓同仁實際使用一兩個月，你會發現當初列的需求有一部分根本用不到，也會冒出當初沒想到的關鍵需求。這個思路和MVP 最小可行產品開發指南一致。
要注意的是可攜性：無論選套裝還是平台，事先確認資料能不能完整匯出、能不能透過介面與其他系統串接。搬不走的系統會在未來限制你的選擇。
要自己養工程師來做，還是交給外部團隊，兩種模式的真實成本比較可以看軟體外包還是自建團隊。
四種常見的失敗
一、做出來沒人用。 系統要求的做法和實際工作方式不一致，同仁在系統之外另外維護自己的紀錄，系統變成多出來的工作。根本原因幾乎都是需求階段沒讓真正的使用者參與。
二、流程沒改，只是換了地方輸入。 把原本混亂的流程原封不動搬進系統，混亂會跟著進去，而且比在試算表上更難調整。導入系統本來就該是整理流程的機會。
三、第一版塞太多。 想著「既然要做就一次做齊」，結果介面複雜、開發期拉長、上線前需求又變了。功能多不等於好用，多數後台真正天天被用到的只有少數幾個畫面。
四、資料沒搬乾淨。 舊資料裡的重複、錯誤與格式不一致被原封不動搬進新系統，上線後數字對不起來，同仁很快就不信任系統。資料遷移的風險與盤點方式，可以看舊系統現代化指南。
五、只有老闆想要。 系統的需求來自管理層想看到數字，但實際輸入資料的是第一線同仁，而他們從系統得不到任何好處。這種情況下資料品質一定會壞掉。解法是讓系統對輸入者也有價值，例如自動帶入常用資料、免去重複填寫、讓他們也能查到自己需要的資訊。
判斷這幾種風險有沒有解除，最直接的方式是在上線前問第一線同仁一個問題：如果明天舊做法被停用，你會覺得鬆一口氣，還是覺得麻煩？ 答案是後者，就代表還有沒解決的問題。
分期上線的作法
後台系統不適合一次全面切換，因為它綁著實際營運，出問題的代價是生意停擺。比較穩的節奏是：
第一階段：一條主線走通。 挑最痛、也最單純的一條流程（例如從接單到出貨），做到能完整跑完，先不做報表與週邊功能。目標是讓一小組人真的每天用它。
第二階段：擴到相關流程與權限。 依第一階段的實際使用回饋調整，再把其他角色與流程納入。
第三階段：報表與整合。 等資料在系統裡累積得夠乾淨，報表才有意義；系統之間的串接也放在這個階段。
每個階段都要有「舊做法停用」的明確時間點。 新舊並行太久，兩邊資料都會不完整，最後誰都不信任系統。
NETVANA 的軟體開發流程以兩週為一個 Sprint，每個週期結束提供可操作的 Demo，正適合這種需要邊做邊調整的內部系統——你可以在真實環境提前試用，而不是等到驗收才第一次看到成品。專案結案時原始碼、設計檔與文件完整移交，後台系統尤其重要，因為它會跟著公司長很多年。
後台系統的價值不在畫面，而在它把散落在各處、只存在某些人腦中的規則，變成整個組織共用的流程。這件事做對了，新人上手更快、交接風險更低、老闆看到的數字也才可靠。
如果你正在評估該用套裝、平台還是客製，或想先釐清流程再決定要投入多少，與 NETVANA 討論你的需求。NETVANA 的顧問服務包含技術架構審查與技術盡職調查，軟體服務採先諮詢再報價，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：需求與驗收標準怎麼寫，可以看軟體需求規格怎麼寫；系統之間怎麼打通，可以看系統整合與 API 串接開發指南；外包與自建團隊的成本比較，可以看軟體外包還是自建團隊；後台通知要推到手機，靠的是機器人串接，可以看LINE 機器人開發指南；後台流程整理好之後，才輪到談 AI 自動化，可以看企業導入 AI 功能指南；後台若要管客戶關係，範圍會擴到會員與 CRM，可以看會員系統與 CRM 開發指南；後台有資料之後，下一步是讓數字自己說話，可以看報表系統與儀表板開發指南；門市場景的後台，跟純內部工具有不同取捨，可以看POS 與門市系統開發指南；內部工具該客製前，先看這套判斷準則怎麼選，可以看買現成 SaaS 還是客製開發；決定要不要客製後台前，先看低程式碼平台撞牆的訊號，可以看低程式碼與無程式碼平台適合你嗎；同樣是試算表該不該換的判斷，這篇看整套 ERP，可以看中小企業 ERP 導入指南。
