開篇：車間牆上的「進度板」為什麼總比系統早兩天
走進一家做機加工的工廠，會議室牆上掛著一塊白板，上面貼著五顏六色的便簽，每張寫著工單號、當班工序、機床號。每晚值班經理都要把便簽換一遍。第二天早上，老闆來車間問：「昨天那批活交齊了嗎？」車間主任掏出那塊板，眯著眼數便簽。
同一個廠，往往會有兩套「進度」：一塊是白板和便簽，一塊是 ERP 或者 MES 裡的工單狀態。前者是現場真相，後者是給財務、對客戶的數字。兩者對不齊是常態，對得齊才是新聞。
這並不是某個廠的特例。我們見過的車間，從十幾人的小作坊到上千人的整機廠，都出現過類似問題：
- 生產計劃下達不到工位：計劃員在系統裡排了 30 張工單，車間只看到 8 張，剩下的「在系統裡掛著」。
- 進度靠問：調度員一天打幾十個電話問「這活到哪了」，工長也記不清幾道工序走到哪裡。
- 工時和實際對不上：報工員每 4 小時填一次表，填到下班前兩小時一起補，數字和真實節拍差 20% 到 40%。
- 異常沒人盯：某道工序等了三天沒料，沒人發現；等到客戶催貨才發現缺一個零件。
問題不在哪個軟體沒用上，而在「現場」和「系統」之間的採集環節斷了。牆上的白板之所以比 ERP 真，是因為它站在機床邊上，由看得見現場的人維護；而 ERP 往往隔了三層：工長到組長到調度員，每一層都重新錄入一遍，每一層都可能晚一步、錯一步。
下面拆一下這套系統該怎麼設計、怎麼落地，才能讓牆上的白板慢慢空下來。
01 業務怎麼拆：把「進度」切成可採集的最小動作
很多項目一上來就把「工序進度」四個字當一個字段寫。其實「工序進度」是一個複合狀態：工單處於哪張工位、由誰在做、已經做了多少、用了多少工時、質量是否合格、物料齊不齊。這六個維度，每個都要獨立採集，不能合一。
具體拆出來是這樣：
- 工位：每台機床或者工位有一個唯一編號，掃碼或刷卡就能定位「現在這台機在幹誰家的活」。
- 作業人：每張工單的開工序、轉移序、報工序，都關聯到一個工號。即使是師徒合作，主操手是唯一記錄人。
- 已做數量：工序有首檢、過程巡檢、完工計數。數量不是狀態，必須按動一下按鈕或者掃一次碼更新一次。
- 實際工時：開工序和完工序的時間差（自動採集），加上中間停頓（手動補登異常停留原因）。
- 質量狀態：首檢、巡檢、終檢三道記錄，合格、返工、報廢獨立流轉，不允許只填合格率。
- 物料齊套：BOM 上每個物料分到齊、未齊、缺料待補三態，與工單狀態聯動。
把這六維都拆成獨立的「事件流」，而不是一組狀態字段。事件是流水賬，誰、什麼時候、在哪台機上、幹到哪段、出了什麼異常，都記下來。狀態是由事件流推導出來的視圖，狀態字段不能由人手填。
02 怎麼設計：把角色、流程、數據、界面邊界畫清楚
設計階段最容易踩的坑是「做個 App 讓人填」，結果營運兩年 App 裡只有登錄頁和密碼一片空白。問題出在角色和界面對不齊。
角色設計
車間裡有四類人，每一類人用的不是同一個界面：
- 操作工：用大按鈕的工位終端或者平板，只看到「我手頭這單」，3 個按鈕：開工、暫停、完工。屏幕上不能出現表格。
- 班組長：用手機或者車間看板，看到本班所有工位的狀態，2 分鐘就能找出「卡在哪」。
- 調度員或者計劃員：用 PC 端，看全廠所有工位的甘特圖加異常列表，重點是排程調整和異常響應。
- 質量或者工藝：獨立入口，看首檢合格率、返工率、SPC 趨勢圖，不直接改工單狀態，只能出「停線」或「放行」。
數據模型
核心四張表，再加幾張輔助表就夠：
- work_order：工單主表，掛銷售訂單、計劃單和產品。
- work_order_route：工藝路線，每個工序節點布多少。
- route_event：工序事件流（核心流水賬），誰、什麼時候、在哪台機、幹到第幾段。
- exception_log：異常日誌（缺料、設備故障、質量返工）。
狀態字段（status、current_step、progress_pct）都是從 route_event 實時算出來的，不存盤；存盤的只有事件。這樣不論誰來改工單，狀態永遠以事件流為準。
界面邊界
三類終端的邊界要畫清楚：
- 工位終端：掃碼 → 調出工單 → 显示工藝 → 大按鈕開工/暫停/完工；不允許填任何數字字段，所有數字由 PLC 或掃碼槍自動寫。
- 班組長看板：本班工位網格化視圖，綠色正常、黃色超節拍、紅色異常。點擊紅色直接跳到異常日誌詳情。
- 調度員 PC：甘特圖加資源負載加異常隊列，異常必須分隊列，不能混在甘特圖裡讓人「找異常」。
03 怎麼開發：採集、介面、驗收三道閘
開發階段的核心命題是「讓現場願意用」。讓現場願意用的前提是「按一下就行」，不是「填一堆」。這背後是三道閘。
採集閘
採集分三層：
- 設備直採：CNC、注塑機、SMT 走 OPC UA 或者 Modbus，把開停機信號、當前程序號、計數實時寫進事件流。這部分最難但價值最高，做完一次就不再依賴人工。
- 掃碼加按鈕：人工工位走掃碼槍（物料）+ 大按鈕（開工/暫停/完工）。掃碼槍走 USB HID，輸出就是字串，不做 OCR、不做圖像識別，現場網路一卡圖像就廢。
- 稱重/計數/光柵：物料過秤、零件計數、安全光柵，都走 PLC 信號轉 OPC。
三層共用一個採集網關服務，網關把不同協議歸一化成統一事件格式（JSON），寫到消息隊列（Kafka 或 RabbitMQ），由訂閱服務消費後寫庫。這樣換設備或者加工位只改網關，不重寫主業務系統。
接口閘
外部接口兩類：
- 上游：ERP 或者 MES 下發工單、銷售訂單、BOM。這是主數據源，本系統只讀不寫，避免雙系統互改工單狀態。
- 下游：財務系統要工時、成本；客戶系統要交付進度；供應商系統要看齊套狀態。下游走「事件觸發」或者「定時拉取」，不允許下游反寫本系統的工單狀態。
接口設計原則：事件流只出不進。本系統是事件源（source of truth），外部系統是訂閱者。這一條規矩守住了，進度永遠只有一套真相。
驗收閘
驗收不是「功能能用」，而是三件事：
- 資料真實性：隨機抽 5 張工單，對照白板或者現場攝像，確認系統記錄與真實開工、完工時間誤差不超過 5 分鐘。
- 異常閉環：造一個缺料異常，驗證從班組長創建、調度員處理、採購補料到工位恢復，全程留痕、且 5 分鐘內能在異常隊列裡看到流轉。
- 節拍對比：連續一周統計每個工位的實際節拍，對比工藝定額，差異超過 30% 自動出預警單。
這三件都過了，才算「工序進度真的看見了」。
收束：落地的順序、風險與指標
這類項目上線分三步走，不要一次到位：
- 第一期（1-2 個月）：先上工位終端加班組長看板，只覆蓋一條產線。目標是「白板上 80% 的便簽能自動同步進系統」。
- 第二期（2-3 個月）：加調度員 PC 加異常隊列加設備直採，覆蓋到全廠主要產線。目標是「現場不再需要打電話問進度」。
- 第三期（按需）：接 ERP、財務和客戶系統，做節拍優化、SPC 分析。這一期不是必做，做完前兩期後看現場反饋再決定。
常見風險：
- 現場抵觸：怕被監控、被比較。解決辦法：界面只顯示工位，不顯示人；指標只做班組級，不做個人排名。
- 採集漏報：老舊設備不帶通訊口，只能用掃碼槍替代。驗收要確認漏報率不超過 5%。
- 工時失真：操作工為了「湊數字」反覆開工停工。系統檢測同一工位 5 分鐘內多次開工，直接計入異常。
檢驗項目成不成的指標只有三個：
- 調度員的電話量：上線後下降 50% 以上。
- 異常平均響應時長：從小時級壓到分鐘級。
- 客戶可查的進度：交付延遲的投訴率下降 30% 以上。
把這三個指標拿到現場，讓牆上的白板空下來，進度這件事就算真做完了。