公司的經驗…跟著員工一起離職

AI Can Generate Answers, But Products Still Require Decisions

Knowledge 不會自己留下來，留下來的是制度。

很多公司都有一個熟悉的場景。

一位老師傅、資深工程師、資深業務、廠務主管，或某個做了十幾年的行政人員要離職或退休。大家開始緊張，趕緊安排交接、請他寫文件、錄影教學，甚至希望他最後幾週「把 know-how 傳下來」。

但幾個月後，新接手的人還是卡住了。

系統出問題，不知道該找誰；客戶有特殊狀況，不知道過去怎麼處理；設備異常時，文件上寫得很簡單，現場卻完全不是那回事；某個流程明明有 SOP，但每次遇到例外，還是得回頭打電話問那位已經離職的人。

於是公司又說：

這個都他處理的。
他走了，很多經驗都沒了。
我們需要做好 KM（Knowledge Management）。

但問題往往不只是 KM 做得不夠。

真正的問題是：公司的知識，從來沒有進入日常工作的流程裡。

Knowledge 不會因為你把文件上傳到雲端、建立 Wiki、買了一套知識庫系統，就自然留下來。文件可以留下，簡報可以留下，錄影可以留下，但真正讓公司持續運作的經驗，若沒有被放進制度、角色、流程與決策機制中，最後還是會跟著人離開。

比起知識管理，更重要的其實是：知識工作流(Knowledge Workflow)。

不是「知識有沒有被存起來」，而是「知識有沒有在每一次工作中被產生、被驗證、被更新、被交接，並且真的被使用」。

老師傅離開的，從來不只是技術

很多管理者以為，老師傅帶走的是某項技術能力。

例如他知道怎麼修設備、怎麼調參數、怎麼處理客訴、怎麼跟某個客戶溝通，或怎麼避開系統裡那些沒人敢碰的問題。

但實際上，他帶走的通常不只是「做法」，而是一整套隱性判斷…

什麼狀況是真的異常，什麼狀況只是短暫波動。
哪一台設備的數據看起來正常，但其實已經快出問題。
哪個客戶嘴上說沒關係，實際上很在意交期。
哪個流程表面上照 SOP 走就好，但到了某個節點一定要先找特定部門確認。
某個系統設定當初為什麼這樣做，碰了會影響哪些舊客戶。
某個供應商報價看起來便宜，但實際交貨與品質風險很高。
遇到跨部門衝突時，真正能拍板的人是誰。

這些內容很難靠一份 SOP 完整寫下來。

因為經驗不只是答案，而是知道在什麼情境下，該用哪一個答案；甚至知道什麼時候不該照標準答案做，如果公司只在員工離職前才開始問：「你可不可以把經驗交接一下？」那通常已經太晚了。

因為對方自己也未必能立刻把十年來累積的判斷，整理成一份人人看得懂、用得上的文件。

KM 最大的誤解：以為把知識存起來就夠了

許多公司導入 KM 時，最後會變成以下幾種形式…

共用資料夾裡有大量檔案，但沒人知道最新版在哪裡。
Wiki 頁面很多，但內容多年沒有更新。
SOP 寫得很完整，但現場根本不照做。
教育訓練簡報很多，但新人上完課還是不會處理真實問題。
有「知識庫系統」，但大家遇到問題還是直接問資深同事。
離職交接表填得很完整，接手的人卻看不懂其中的關鍵判斷。

這些不是知識不存在，而是知識沒有活在工作裡。

一份文件若沒有明確的使用時機、維護責任與更新流程，最後就只是儲存資料，而不是累積能力。

公司不缺文件，公司缺的是讓文件能被持續驗證與更新的工作機制。

例如，一個客服案例可以整理得再完整，如果下一次遇到相似問題時，客服人員不會回頭查、不會補充新的處理方式、不會標記哪些做法已失效，那它就只是一次性的紀錄。(我想到有AI小工具可做了…哈)

一套設備維護 SOP 寫得再漂亮，如果每次故障後都沒有回頭修正「原本 SOP 漏了什麼」，那公司就會持續依賴某個人的現場直覺。

KM 若只是一個專案，最後通常會失敗，因為知識不是「建好」就結束，而是每天都在變動。

真正重要的是知識工作流

知識工作流…不是建立一個更漂亮的知識庫，是把知識管理嵌入工作流程中，讓知識不是額外負擔，而是工作完成後自然留下的成果，一個有效的知識工作流，至少包含幾件事…

在問題發生時留下情境，而不只留下結論

很多公司只記錄：「問題已排除」、「客戶已處理」、「設備已修好」。但這種紀錄對下一個人幫助很小，更有價值的是留下…

當時發生什麼問題？
怎麼發現的？
影響範圍是什麼？
嘗試過哪些方法？
為什麼最後選擇這個做法？
哪些條件下不能套用？
下次怎麼更早發現？

知識真正有價值的地方，不只是「最後怎麼解」，而是「當初為什麼這樣判斷」，這會讓新人不只是複製資深員工的動作，而是逐漸理解判斷邏輯。

把例外流程留下來

公司最危險的知識，往往不在正常流程，而在例外流程，正常流程通常大家都有文件，也容易交接。真正依賴資深人員的，是那些不正常但經常發生的狀況：

客戶臨時改單怎麼處理？
系統資料不同步時誰能判定正確版本？
供應商延誤但客戶不能延後時怎麼協調？
品質異常到底能不能放行？
某些舊設備發生特定警報時，標準手冊不適用怎麼辦？
專案需求與既定排程衝突時，誰來決定取捨？

如果公司只記錄「標準做法」，卻不記錄例外情境與決策路徑，最後一定還是要靠人。

因為現實世界從來不只由標準流程組成。

明確指定知識的主人

知識庫最容易失效的原因之一，是沒有人負責。

文件寫完後，誰更新？
流程改了以後，誰確認 SOP 是否失效？
新人照著做卻出錯，誰回頭修正內容？
某個資深員工提供的經驗，誰判斷它是否還適用？

這些都不能只靠「大家有空再補」。

每一份關鍵流程、每一個重要知識領域，都需要有明確的 owner。這個人不一定要親自寫所有內容，但要對內容是否可用、是否更新、是否有人接手負責。

沒有 owner 的知識，最後一定會過期，而過期的知識，比沒有知識更危險。因為它會讓人以為自己照流程做了，卻在錯誤的前提下做出錯誤決策。

讓知識在工作中被使用，而不是只在稽核時被打開

如果一份 SOP 只在 ISO 稽核、主管檢查或新人訓練時被拿出來，它很快就會失去生命力。真正有效的知識，應該出現在工作上…

客服建立案件時，系統自動推薦相似案例與處理原則。
工程師處理事故時，結案流程要求補上原因、影響與預防措施。
業務報價前，可以查到客戶過去的特殊條件與風險紀錄。
新專案立項時，必須回顧過去類似專案的成本、延誤原因與決策紀錄。
設備保養時，現場人員能直接看到過去異常與處理歷程。
部門交接時，不只是交檔案，而是用實際案例確認接手者能否完成工作。

知識被使用，才有機會被發現錯誤、補充例外、持續變好。

AI 可以整理知識，但無法替公司建立責任

現在很多人會說，AI 可以解決知識傳承問題。確實，AI 可以做很多事…

把會議紀錄整理成重點。
將散落的文件建立摘要與分類。
從歷史案件中找出相似案例。
協助新人快速查詢 SOP。
把資深人員的訪談轉成初步知識文件。
協助找出不同文件之間的矛盾。

這些都很有幫助，但 AI 無法決定…

哪一份資料是正確的？
哪個流程應該更新？
誰有權改規則？
哪一項風險可以接受？
哪個經驗只是個人習慣，而不是公司應該複製的方法？

AI 可以整理知識，但不能替組織承擔責任。AI很會說…下次說法可能會不同，如果原本的資料就是過期的、錯誤的、互相矛盾的，AI 只會更有效率地把混亂整理得看起來很有條理。

所以，導入 AI 前真正該問的不只是想我們要不要做 AI 知識庫…

我們現在的知識，誰負責？
哪些內容是真正工作上會用到的？
哪些流程會讓知識持續被更新？
當現場做法與文件不同時，誰來判定該改現場，還是改文件？

沒有知識工作流，AI 只是一個更快的搜尋工具。有了知識工作流，AI 才可能成為放大組織能力的工具。

不要等到有人離職，才開始做知識交接

最糟糕的知識管理時機，就是員工提離職後，可能會發現…

原來只有他知道這個系統怎麼維護。
原來這個客戶的歷史問題沒人整理。
原來關鍵設備沒有完整保養紀錄。
原來某些流程根本沒有真正的接手人。
原來主管以為有 SOP，現場其實一直靠口耳相傳。

知識傳承不該是一場離職前的搶救，它應該是日常管理的一部分，每一次專案結束、每一次重大客訴、每一次設備異常、每一次流程例外、每一次跨部門衝突，都應該是公司把經驗留下來的時刻。

不是要求每個人寫長篇報告，而是建立一套足夠簡單、足夠靠近工作現場的機制，讓大家知道該留下什麼、放在哪裡、誰來確認、何時更新。培養習慣，凡事起頭難，但該做的就是要養成習慣去建立。

公司真正該留下的，不是某個人的答案

公司不可能保證每一個資深員工永遠不離開。

人會退休、轉職、生病、調職，也可能只是突然休假兩週。若一個人的不在，就能讓流程停擺、客戶無法處理、系統無人維護，那問題不在於這個人太重要，而在於公司把太多能力綁在一個人身上。

真正成熟的組織，不是沒有高手，而是高手的經驗，能逐步變成團隊可理解、可使用、可驗證、可更新的共同能力。

老師傅的價值，不是永遠當那個「只有他能解決問題的人」。而是讓下一個人遇到類似問題時，不必從零開始猜。

經驗知識不會自己留下來，留下來的，從來不是一堆文件、幾場交接會議，或一套看起來很厲害的 AI 系統。真正留下來的，是一套經驗制度…

問題發生時，有人記錄情境。
決策做出後，有人留下理由。
流程改變後，有人更新內容。
經驗被使用後，有人持續驗證。
人離開後，工作仍然能繼續。

公司才能累積重要的經驗資產。沒有…頂多就是在重新來…客戶可能也重新來…