部門主管的時間，很大一塊花在重複的事情上：回答已經回答過的問題、找一份不知道被誰改過的文件、把同一套流程再教一次給新來的人。McKinsey Global Institute 2012 年的經典研究估計，互動型知識工作者有 19% 的工作時間花在搜尋和蒐集資訊。知識沒有沉澱下來，每個人就得自己重新打聽一次，這 19% 是最貴、也最容易被忽略的隱形成本之一。
知識管理和教育訓練，其實是同一件事的兩面：把該留下來的知識留下來、把該學會的人教會。以下整理部門主管最常遇到的十個問題，逐題給可以馬上動手的解法。先講一句定調的話：工具能幫你把知識庫建起來，但願不願意寫、有沒有人維護，是制度問題，不是功能問題。這條界線會一路貫穿下面十題。
SOP 與教材：寫了卻沒人用
文件沒人用的問題，九成出在放置的地方，而不是內容的品質。SOP、教材、流程說明寫得再好，只要放在一個沒人會主動打開的地方，就等於沒寫。前三個問題，都是這個症頭的不同版本。
Q1：SOP 寫了沒人看，怎麼辦？
SOP 沒人看，多半和內容好壞無關，問題出在它被放在一個沒人會主動打開的地方。存在共用資料夾或個人硬碟裡的 SOP，要先下載才讀得到、搜尋只找得到檔名，還常常好幾個版本並存。把它搬進知識庫：頁面點開即讀、內文可以直接搜尋、更新即生效，找得到才有被遵守的可能。工具能做到的到此為止；至於「找到之後照不照著做」，是管理與稽核的事，不是換個工具就會自動發生。有個實用的小習慣：有人在群組問已經寫成頁面的問題時，回覆連結而不是重打一次答案，慢慢養出全公司「答案在知識庫」的反射。
Q2：培訓教材散在各部門硬碟，怎麼集中？
培訓教材散落各處的根因，是沒有一個全公司都知道去哪找的中心。解法是把教材集中進知識庫：無論是簡報、文件，還是既有的 Word、PPT、心智圖檔案，都能上傳或匯入知識庫，用樹狀的頁面層級歸類，新人訓練放一區、產品教育訓練放一區、工具操作放一區。Lark 的簡報本來就以製作教育訓練與管理簡報為設計場景，教材和知識庫長在同一個雲端裡，改一次全公司看到的都是新版，不會再有「你手上那份是舊的」。
Q3：新人問題重複回答一百次，怎麼減少？
重複回答一百次的問題，值得寫成一頁、一次解決。把最常被問的問題整理成知識庫裡的常見問題頁，再配一份新人入職指南，新人第一週的多數疑問就能自己查到答案，資深同事從人肉客服的角色解放出來。判斷哪些該寫的標準很簡單：同一個問題被問過三次，就寫成頁面。這是知識庫裡最快回本的一塊，入職指南的黃金結構有完整範本。要提醒的是，寫好了不代表新人就會先查；養成「先查再問」的習慣，仍要靠主管在被問到時先反問一句「知識庫查過了嗎」，工具只提供答案的存放處。
知識只在人腦裡：留不住的經驗
知識留不住的公司，通常不是沒有能人，而是能人的經驗從來沒有離開過他的腦袋。當關鍵流程只存在資深員工的記憶裡，公司就把營運的連續性押在「這個人不會走、不會忘、不會請假」上。接下來三題，是知識從「人」回到「組織」要跨過的三個坎。
Q4：員工離職，交接不完整怎麼辦？
離職交接不完整的根本原因，是知識平時沒有沉澱、拖到離職才臨時打包。解法要分兩層。制度層面，讓工作紀錄平時就長在知識庫與雲端文件裡，交接時交的是「位置」而不是「記憶」；搭配管理後台的離職資源移轉，把帳號停用、資源移轉、文件歸屬一起處理，頁面歸屬轉給接手的人，樹還在、知識就還在。誠實說，工具承接得了可以寫下來的那一半；至於只可意會的判斷與人脈，仍需要一段交接期由人對人傳，別指望系統把這塊也補上。
Q5：部門知識只在老鳥腦袋裡，怎麼顯性化？
部門知識卡在老鳥腦袋裡，是因為那些經驗從來沒有被要求寫下來。知識庫提供了載體，但把隱性經驗變成頁面，真正的關卡是誘因與制度，不是功能。可行的做法是從「被問最多的問題」下手，讓最常被問的人來寫答案，他們最知道大家卡在哪；再把「寫下來」排進他的正式工作，而不是有空才做的佛心事。Atlassian《The State of Teams 2026》訪調 12,035 位知識工作者，其中 87% 的知識工作者表示大家都埋頭各自執行、缺乏協調彼此的時間與餘裕；知識不流通，正是這種各自為政的來源之一。把老鳥腦中的經驗變成可查的頁面，就是在拆掉它。
Q6：文件更新後，舊版還在流通怎麼辦？
舊版還在流通，是檔案時代的老問題：每改一次就多產生一個副本，最後沒人分得清哪份是準的。知識庫的頁面始終是同一份、更新即生效，讀者打開的就是最新版，副本滿天飛的問題從源頭消失，這也是單一事實來源的核心。萬一改壞了、或想看誰在什麼時候改了什麼，雲端文件本身有版本管理：可查看編輯記錄、還原到之前的歷史版本；打開檔案的歷史記錄，能看到依時間倒序、含修改人與時間的版本。更新有紀錄、舊版可回溯，大家才敢放心共編同一份。
建得起來，也要養得下去
知識庫的成敗，多半不在建置那一天，而在建好之後有沒有人持續經營。把庫建起來只是起點；分類怎麼切、誰來維護、怎麼讓人願意寫、和聊天記錄如何分工，這四題決定了它會變成活的中心，還是沒人打開的墳場。
Q7：知識庫要怎麼分類？
知識庫的分類原則是照讀者尋找的路徑分，而不是照組織架構圖分。新人不知道「行政部」管什麼，但知道自己要找「怎麼請假」。用知識庫的樹狀頁面層級把第一層切成使用者找得到的區塊，建議不超過六個，例如公司制度、入職指南、部門 SOP、教育訓練、常見問題。有一個限制要記得：知識庫用的是頁面層級，並不支援像檔案總管那樣建資料夾，所以分類的心力要花在頁面的父子結構上，而不是套用舊的資料夾習慣。第一層結構怎麼設計，企業知識庫搭建 SOP 有更細的拆解。
Q8：知識庫該由誰來維護？
知識庫的維護要拆成兩件事：系統層面的管理員，和內容層面的每區負責人。系統層面，Lark 知識庫有三種管理員，分別是企業超級管理員、知識庫功能管理員與知識庫管理員，負責建立、權限與後台治理。但真正決定知識庫活不活的，是內容層面：每個區塊指定一位負責人，頁面有主人才有人更新。依我們導入輔導的經驗，這份工作量不大，每區負責人每週大約半小時就夠，但一定要有名有姓；掛在「大家」身上，等於沒人負責。判斷哪些頁面該修，打開檔案資訊看閱讀人數與次數是個好訊號：長期沒人讀的標註封存，又開始被頻繁查閱的優先更新。
Q9：怎麼讓大家願意寫文件？
讓大家願意寫文件，靠的不是工具功能，而是管理層帶頭和把書寫綁進工作流程。這件事沒有工具能代勞，但有幾個做法會明顯提高意願。第一，管理層帶頭：主管自己先把交辦、公告、決策寫進知識庫與文件，組織才會跟上；依我們協助台灣企業導入的經驗，管理層不帶頭示範的案子，多半三個月內就退回原狀。第二，把更新綁進流程：制度一改版，同步更新頁面就是發布流程的一環，不是事後有空才補。第三，降低書寫門檻：用現成範本起手，別讓「排版」變成不寫的藉口。寫文件的意願，是設計出來的，不是要求出來的。
Q10：知識庫和聊天記錄要怎麼分工？
知識庫和聊天記錄的分工，一句話就能說清：訊息負責流動，知識庫負責沉澱。聊天記錄是流動的：結論會被後面的訊息一路往下推，三個月後沉進訊息海，本來就不是設計來被反覆查閱的。需要多人共同編修的工作產出，例如提案、會議紀錄、專案文件，活在雲端文件；當一份內容從「進行中」變成「定案且會被反覆查閱」，才整理進知識庫。方向是單行道：訊息裡的結論寫進文件、文件裡的定案沉澱進知識庫，反過來把草稿全塞進知識庫，它就會退化成沒人想開的雜物間。訊息、文件、知識庫三者為什麼最好放在同一個平台，企業協作平台選型指南有完整說明。
起步：先小後大
知識管理不必一次做到位，最務實的起手式是一個區塊、一位負責人、十個頁面。與其宣示「全公司知識大遷移」然後半途而廢，不如挑最快回本的入職場景與最常被問的十個問題先做，跑一個月，讓「有問題先查知識庫」成為部門的預設動作，再擴到下一個區塊。教育訓練也一樣：先把一份新人能自己走完的入職頁面寫好，比辦十場口頭訓練都省力。回到開頭那句話：工具能把知識庫建起來，願不願意寫、有沒有人維護，仍是制度問題，而制度，是主管可以設計的。
想盤點你們部門現有的文件、規劃知識庫的第一層結構，找艾瑞特資訊聊聊。身為 Lark 台灣授權代理商，我們最常做的第一件事，就是用你們手上現有的 SOP 和教材，現場示範第一層怎麼切、第一批內容怎麼挑。