前言：寫下來，不代表制度已經成立

公司開始用 Agent 整理知識後，很容易產生一種錯覺：文件變多，流程就會自然變好。

我實際遇到的情況相反。若文件只有原則，現場仍然不知道誰決定、何時停工、要留下什麼證據。若 Agent 又把草案說成正式規定，問題會更嚴重。

所以我們整理工程 SOP 時，第一個決定不是怎麼寫得完整，而是先把三種狀態分開：現況證據、建議制度、待核准事項。

────────────────────

從一句「工程去處理」拆成完整交付鏈

ZoneTech 的外務工程，涉及業務、工程、客戶與主管。以前一句「安排工程去現場」，藏了太多未定義工作：需求誰確認、資料誰收、設定何時完成、超時誰決定、成果由誰驗收。

整理後的外務工程 SOP 接近三百行。流程不從工程出發開始，而是從報價與維修單成立開始：

1. 業務確認需求、範圍與限制。
2. 客戶確認報價後建立維修單。
3. 業務完成需求交接並簽名。
4. 工程確認資料完整後，才開立 Pre-setting。
5. 公司內先完成設定與測試準備。
6. 到場施工、測試、拍照與錄影。
7. 業務對照原始需求確認成果。
8. 完工後追蹤客戶滿意度與改善事項。

這裡最重要的不是步驟數量，而是「不可進入下一階段」的條件。需求不明、業務未交接、客戶資料缺漏，就不能靠工程師猜測後直接設定。

────────────────────

SOP 必須定義停止，而不只定義前進

許多流程文件只描述順利情況。真正燒成本的，卻是現場異常。

我們在 SOP 中明確寫下：標準現場服務原則上抓三小時。超時不能安靜離場，也不能硬做到底。工程要回報已完成、未完成、原因、客戶影響、額外資源與下一步，再由有權限的人決定續作、改期、拆分或重新報價。

同樣地，公司原則上不承接一般拉線。現場若發現新增拉線、特殊施工或原報價外工作，工程不能自行承諾價格與工期。

這是我踩過的重要觀念：SOP 的價值不只是讓人知道怎麼做，也要讓人知道何時不能繼續做。

────────────────────

台南案：換一台 Router，為什麼最後必須撤場

台南的轉介紹案件，把這個缺口照得很清楚。

工程到場後發現，中華電信帳號密碼不正確，現場線路位置也不正確。原本看似更換一台 Router 的工作，實際牽涉線路重新整理，以及三條中華電信線路：一條上網、兩條健保專線。

若只用「今天要完工」評價工程師，最可能發生的事就是繼續碰運氣。結果可能是錯誤設定、無償擴大施工，甚至二次進場重工。

正確決策是先停止錯誤路徑。工程保留線路、設備與現場證據；必要時撤場。顧問再把新增拉線與配置需求轉成客戶看得懂的重報價。客戶確認範圍後，重新做 Pre-setting，再安排進場與驗收。

這個案例也讓我們重新定義「顧問」。顧問不是只負責成交，而是客戶需求、公司承諾與工程交付之間的決策者。

────────────────────

職位說明不能只有責任，還要有授權邊界

顧問收到異常回報後，至少要能判斷四條路：繼續、暫停、撤場、升級主管。

但文件不能假裝所有權限都已確定。顧問可自主決定的金額、毛利底線、撤場是否需即時批准、夜間異常時限，目前仍屬待核准項目。

因此我們在文件 metadata 與正文都標示 proposed。這不是保守，而是避免 Agent 把建議制度冒充公司正式規章。

────────────────────

KPI 不該獎勵「快速把案件關掉」

若只看案件量、工時或結案速度，團隊會自然優化錯誤目標。問題沒解決也先結案，照片沒補齊，風險晚點再說。

我們把工程評核拆成多個構面：交付品質與客戶結果、技術能力、SOP 與文件、回報溝通、效率責任、團隊協作。升遷也不能只看總分，還要檢查最低構面、連續期間與代表案件證據。

真正可用的證據包括工單、施工前後照片、測試結果、驗收紀錄、客戶回饋、重工與根因分析。主管不能只寫「態度不好」或「能力不錯」。評語必須連回事實、影響與改善要求。

這也避免另一個陷阱：客戶滿意度不能單獨決定工程師好壞。案件難度、資料完整性、現場限制與需求變更，都要一起判斷。

────────────────────

Agent 在這裡扮演什麼角色

Agent 很適合把散落在 Drive、工作說明書、維修單與口述經驗中的規則，整理成可檢查的流程。它也能找出缺少 owner、輸入、輸出與驗收證據的段落。

但 Agent 不能代替管理層核准薪資、權限與績效規則，也不能把一個案例直接推廣成永久制度。

我們採用的做法是：先整理草案，再用最近一季案件回測。若 SOP 套回真實案件，能更早發現缺件、停止錯誤施工、留下可追溯證據，才有資格進入試行。試行後再調整權重與門檻。

────────────────────

實際證據

這次不是只產生一頁原則。我們已建立外務工程流程草案、顧問現場決策 SOP，以及工程師考核與升遷制度草案。三份文件都明確標示 owner、狀態、交接、例外、驗收證據與待核准事項。

台南案也被轉成可回測的決策鏈：資料與線路異常、停止施工、保留證據、撤場重報價、重新 Pre-setting、再進場驗收。它讓「有經驗的人會判斷」，變成下一位同事與 Agent 都能遵循的組織知識。

下一篇，我會處理另一個常見落差：公司內部有 Obsidian 文件，不代表全公司都能取得。D14 將談如何把知識輸出到 Google Docs，以及公司帳號與個人帳號混用造成的 403 教訓。