Excel 流程與營運系統
公司還在用 Excel 管理營運，什麼時候該做客製化管理系統？
從檔案版本、資料規則、多人權限與跨部門流程，判斷 Excel 是否已成為營運瓶頸，並了解資料移轉、系統建置與驗收的完整做法。
Excel 很適合快速整理資料、試算與驗證新流程，因此問題從來不是企業用了 Excel，而是原本的工作表是否已在不知不覺中承擔客戶、訂單、課程、庫存、付款或排程等核心營運責任。當多人每天依賴同一批資料工作，卻仍靠檔名、欄位顏色、複製貼上與特定員工記憶維持運作，企業需要評估的就不只是換工具，而是如何把已經成立的工作規則整理成可驗證、可交接、可持續擴充的管理系統。
具體客戶問題與難點：Excel 已經變成沒有規格書的內部系統
常見問題不是資料列太多，而是同一筆資料沒有穩定身分。客戶名稱可能有全名、簡稱與錯字，訂單編號可能由不同同仁各自編排，付款狀態則同時出現「已付」「完成」與儲存格底色。當欄位沒有共同定義，兩張表即使看起來記錄同一件事，也很難可靠合併；主管看到的總額、業務追蹤的進度與財務認定的應收便可能彼此不同。
多人協作會再放大風險。有人下載副本後離線修改，有人為了做報表新增公式，另一位同仁又把舊版覆蓋回共用資料夾。敏感的價格、毛利與個人資料也常跟一般作業欄位放在同一個檔案，難以做到依角色限制查看或修改。即使雲端試算表改善了共同編輯，它仍不會自動定義誰能核准折扣、何時才能出貨、狀態改變後要通知誰，以及每次異動是否需要留下可追查的紀錄。
以一家培訓公司為例：團隊使用不同工作表管理企業客戶、課程梯次、學員名單與收款。業務修改公司名稱後，財務表仍保留舊名稱；學員換梯次時，客服更新了名單，講師的點名表卻沒有同步。到了月底，團隊並非找不到資料，而是無法確認哪一份才代表真實狀態。
- 同一客戶、商品或案件在不同檔案中有不同名稱與編號
- 資料需要重複輸入到報價、訂單、排程、收款與報表
- 關鍵公式與例外規則只存在少數同仁的記憶裡
- 無法依角色限制欄位、操作或敏感資料，也缺少完整異動日誌
何時值得做：先確認流程是否已超過試算表適合承擔的責任
如果流程由單一人員管理、資料生命週期短、錯誤容易修正，也沒有權限、核准或跨系統需求，維持一份結構清楚的 Excel 可能仍是最有效率的做法。客製系統不是為了消滅所有試算表，而是把會影響營收、交付、客戶權益或管理決策的共同流程，移到有一致規則的環境。分析與臨時試算仍可以保留在 Excel。
當三人以上經常共同維護同一流程、同一資料需要跨部門複製、錯誤會造成重複出貨或漏收款、主管需要即時查詢，或企業開始要求角色權限與操作日誌時，通常就值得進一步評估。另一個明顯訊號是團隊為了避免出錯，不斷增加鎖定欄位、巨集、檔名規則與人工檢查；這代表企業已經在自行維護一套系統，只是它沒有正式資料模型、測試與維運方式。
AgentTech 會把評估範圍收斂到一條有明確起點與終點的流程，例如「客戶確認訂單到完成收款」或「學員報名到取得課程權限」，比較每月重複輸入次數、等待時間、修正成本與責任風險。只有在系統化能降低這些成本，且規則已穩定到可以被說清楚時，才建議進入客製建置。
- 值得優先處理：高頻、多人、跨部門、錯誤成本高且規則相對穩定
- 暫不客製：低頻、一次性、規則仍快速變動或只需個人分析
- 可先改善：統一欄位、編號與責任人，再觀察是否仍有系統需求
AgentTech 方法與技術設計：先定義資料，再把流程與責任落進系統
AgentTech 會先訪談實際操作人員並盤點所有輸入、輸出與例外，建立資料字典。資料字典不只列出欄位名稱，還會定義型別、必填條件、允許值、來源、負責人、保存方式與敏感等級。接著辨識客戶、公司、訂單、課程或付款等核心實體，為每筆資料建立不會隨顯示名稱改變的 unique key；若舊資料已存在外部編號，則保留為 alternate key，讓匯入、查找與其他系統串接有穩定依據。
歷史檔案不會直接寫進正式資料庫。原始資料會先進入 staging 區，保留來源檔名與列號，再依規則標準化日期、金額、電話、統一編號與狀態。重複資料會用 unique／alternate keys、欄位組合及人工覆核清洗；確認後再透過 upsert 建立或更新正式紀錄，避免試轉時重複新增。無法自動判定的衝突會進入例外清單，而不是被程式靜默覆蓋。
正式系統會依工作責任設計多人權限，例如業務可建立訂單但不能查看毛利，財務可確認付款但不能改動已核准價格，主管則能核准例外並查看報表。重要的新增、修改、核准、匯出與刪除都留下操作者、時間與前後值日誌。流程狀態、欄位驗證、資料庫約束、通知與 API 共同防止錯誤，而不是只依賴前端畫面提醒使用者。
- 流程圖與資料字典：說清楚資料、狀態、責任與例外
- 資料模型：unique key、alternate key、關聯、必填與一致性約束
- 移轉管線：staging、清洗、去重、upsert 與例外覆核
- 營運控制：角色權限、核准規則、操作日誌、通知與可追蹤 API
分階段落地：試轉、對帳、切換與回滾都要在正式上線前演練
第一階段會凍結一份舊資料快照，用真實但經妥善保護的資料執行試轉。每次試轉都記錄讀取筆數、成功筆數、拒絕原因、去重結果與轉換後總額，並由熟悉業務的人員抽查關鍵客戶與例外案件。若新舊系統的訂單數、應收總額或學員權限不同，必須先找到差異來源，不能以「大致相同」通過。
第二階段選擇一個團隊或一條流程試用，讓使用者在真實工作中驗證欄位、權限、查詢、匯出與例外處理。必要時可短期平行運行，但必須明確指定哪一套是 source of truth，以及舊表在什麼時間後改為唯讀，避免兩邊同時修改形成新的版本衝突。試行期間收集的是可重現問題與流程差異，不是無限制加入新功能。
正式 cutover 前會再做增量移轉與最終 reconciliation，確認備份、維護窗口、通知對象與停止舊表寫入的時間。若筆數、金額、權限或關鍵流程未通過門檻，就依 rollback 計畫恢復舊流程，保留新系統紀錄供修正後重試。切換成功後仍會觀察錯誤率、未處理例外與使用狀況，再逐步加入報表、自動化或其他部門。
- 試轉：可重複執行且不污染正式資料
- 對帳：比較筆數、金額、關聯、狀態與抽樣紀錄
- 切換：明確凍結時間、source of truth、責任人與通報路徑
- 回滾：保留備份、操作步驟、判斷門檻與重新切換條件
最終交付物與驗收：交付的不只是後台畫面，而是可營運的資料與流程
AgentTech 的交付範圍會依專案確認，通常包含現況流程與優先順序、資料字典與資料模型、歷史資料清洗規則、可重複執行的移轉工具、多人使用的營運後台、角色權限與操作日誌、必要的查詢報表、備份監控，以及操作與切換文件。若需與網站、LINE、金流、物流或既有 ERP 串接，也會留下介面規格、錯誤處理與重送方式。
驗收不應只確認按鈕能否點擊。資料面需核對來源與目的地的筆數、金額、unique key、關聯及重複率；權限面需逐一測試各角色能看見與操作的範圍；流程面需讓代表使用者完成正常、退回、取消與例外路徑；營運面則要完成備份還原、切換與 rollback 演練。所有未通過項目要有明確責任人與處理期限。
完成後，企業得到的產品是一套以正式資料庫為基礎、可供多人共同操作的客製管理系統，並附上資料定義、移轉結果、測試依據與維運方式。Excel 可以繼續用於臨時分析與匯出，但不再需要承擔唯一真相、權限控制與關鍵流程執行的責任。
- 產品：營運後台、角色權限、流程狀態、查詢報表與必要整合
- 資料：資料字典、模型、清洗規則、移轉程式與對帳結果
- 品質：功能、權限、例外、效能與備份還原測試紀錄
- 營運：使用手冊、切換／回滾 Runbook、監控與後續版本建議
這篇文章適用的服務
客製系統與數位平台
SYS Agent
需求診斷、CRM、電商、會員、預約、營運後台、資料權限、API 整合與部署維運。