C# .NET Blazor MAUI Xamarin Research

30種企業知識庫應用 25 證券與投顧

七點半晨報審核挑出一句產業展望，那句話沒有錯，但沒有人記得前提與出處；翻出來的會議紀錄只有「討論產業展望」六個字，九點半只好把觀點刪掉，報告晚了兩小時發出去。這一集示範怎麼把兩小時研究會議變成問得到「前提是什麼、出處第幾分鐘」的依據鏈，以及為什麼在這一行，系統只能提案、生效一定要有人簽名。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進證券與投顧。

畫面上那一句副標，就是這一集的全部：把每一句觀點，變成追得回來的黃金依據鏈。

請注意「追得回來」這四個字。

在別的行業，講錯一句話是溝通問題；在這一行，講出去的每一句都可能被主管機關拿去逐字檢視。

所以這一集談的不是效率，是風險。

我們看一個早上發生的事。

七點半，晨報合規審核。

有一句產業展望被挑出來——那句話本身沒有錯，但沒有人記得前提是什麼、出處在哪裡。

七點四十五，翻找紀錄。

找到的會議紀錄只有六個字：討論產業展望。

九點半，最後的處理是刪掉那個觀點，報告晚了兩小時發出去。

請注意，被刪掉的是一句正確的話。

刪它不是因為它錯，是因為它證明不了。

右邊那個問題，是給所有主管的：過去半年發出去的報告，有多少句面臨同樣的風險？

這一頁把問題的形狀畫出來了，三座階梯，一座比一座矮。

第一座最高，叫「我知道」——分析師腦中的推論與記憶，這一塊其實非常厚實。

第二座矮一截，叫「說得出來」——寫在報告上的，只剩簡短的結論。

第三座最矮，叫「留得下依據」——經得起合規逐字檢視的原始出處。

兩個不等號，就是兩次流失。

所以標題講得很準：不是不嚴謹，是流程有斷層。

分析師的嚴謹留在第一座階梯上，走不到第三座。

為什麼一定會斷？

畫面上四道裂痕。

左上，過程變文字。一場兩小時的研究會議，最後濃縮成三句話，中間的推理與假設全部蒸發。

右上，來源太多元。法說會、公司拜訪、外部報告——一個結論背後可能有五個來源，散落在不同人的資料夾裡。

左下，時間壓力。每天要出晨報的節奏下，沒有人有時間為每一句話標註來源。

右下，分析師流動。人一走，推理跟著走，留下來的報告就變成「無主的結論」。

最後這一格特別麻煩——那句話還印在報告上，但公司裡已經沒有人能解釋它。

那要怎麼補？

畫面左右兩邊，是兩種完全不同的想像。

左邊打叉的，是把知識庫想成雲端硬碟，或者單純把檔案丟給人工智慧。

這條路解不了問題——因為第四頁那四道裂痕，沒有一道是「檔案沒地方放」造成的。

右邊是正確解法，畫面上叫它知識煉油廠。

副標那一句是關鍵：觀點形成的過程，必須被完整留下並隨時查得到。

請注意是「過程」，不是結論。

結論本來就在報告上，缺的一直是過程。

實際的產線分三個階段。

階段一，原料匯入：研究會議的錄音、逐字稿，還有公司拜訪的筆記。

這一步的成本很低——會議本來就要開，錄下來就好。

階段二，清洗程序：去掉贅字，把敏感資訊蓋掉，然後分類、摘要。

階段三，蒸餾概念，生成可以互相連結的知識積木。

畫面上用積木來比喻很貼切：一場會議不會只變成一份紀錄，它會被拆成好幾塊，每一塊都可以被別的報告接上去。

實際問一句話，拿到的東西長這樣。

提問是：這個產業下半年的展望，我們的依據跟前提是什麼？

答案分成三塊。

第一塊，結論：下半年優於上半年。

這一塊分析師本來就知道。

第二塊，不可忽略的前提：原料價格不再上漲——如果漲幅超過一成，毛利改善會被抵銷，所以這個前提必須一併陳述。

這一塊，就是第二頁那個早上找不到、最後只好刪掉觀點的東西。

第三塊，黃金依據鏈：依據是產業報告與公司拜訪，出處是某月研究會議錄音，原始逐字稿第四十一分鐘。

有了這三塊，那句話就發得出去了。

這一頁只有一句話，但它是整集的核心，值得停下來想一下。

您要留下來的不是結論，是結論成立的條件。

為什麼？因為結論會過期，條件不會。

「下半年優於上半年」這句話，三個月後可能就不成立了。

但「原料價格漲幅超過一成，毛利改善會被抵銷」這個條件，明年還在用。

而合規要看的、稽核要問的，也一直都是條件，不是結論。

接下來這一頁，是這一行跟其他行業最不一樣的地方。

標題問得很直接：錯了誰負責？

副標更直接：任何會自動產生、自動發布內容的機制，在這一行都不可接受。

畫面左邊是一般產業的追求：速度與自動化發布，齒輪一轉到底。

畫面右邊是證券投顧業的追求：當責。

底下寫著嚴格的人工審核與可追溯記錄。

請注意，右邊那個盾牌裡面是一份有簽章的文件。

在這一行，一句話發出去之前，必須有一個人的名字掛在上面。

這件事不能自動化，也不該自動化。

那怎麼落實當責？

畫面上這兩道門，就是機制。

第一道門，系統只能提案。

整理出來的草稿放在這裡，而且請看那行附註：此狀態絕對查不到。

不是藏起來、不是排在後面，是根本查不到。

中間那把鑰匙，是人類專家核可——可以修改、可以退回、也可以刪除。

第二道門，正式生效。

只有核可過的內容，才會進到知識庫裡被查到。

副標把設計原理講完了：把「產生」跟「生效」徹底拆開。

機器負責產生，人負責生效。

責任就落在拿鑰匙的那個人身上。

導入的時候有四條鐵律，畫面上四格。

鐵律一，審閱成本不可省。人工核可是有成本的，這個成本必須事先算進去，而且要排進職責，不能靠自願。

多數導入失敗就死在這一條——買了系統，卻沒有人有時間審。

鐵律二，版本化而非覆蓋。觀點更新之後，舊版要轉成已汰換，而不是被蓋掉。

因為稽核會問的是：當初核可的是哪一版。

鐵律三，每次問答皆有稽核明細。誰問了什麼、引用了哪幾段素材，都要留下完整軌跡。

鐵律四，也是最重要的一條：僅限內部參考。它的產出是內部共識，絕不取代既有的對外發布與合規審查程序。

合規複核這件事，導入前後差在哪？

畫面左邊是沒有系統的時候，靠的是印象：查找時間長、退回修改的比例高、分析師一異動就斷層。

畫面右邊是有系統之後，靠的是紀錄：一鍵調出當時的討論與前提、退回比例顯著下降、知識資產化永久保留。

底下那條大箭頭把它總結成一句：同樣一句話，從印象變成紀錄。

這句話對合規長特別有意義——他不再需要憑感覺決定放不放行。

這件事的效益，三種人各有一份。

畫面上三根柱子，撐起同一個屋頂。

第一根，分析師：寫作有底氣。不再害怕忘記出處，可以專注在觀點的推演上。

第二根，合規長：審核有依據。不再憑感覺放行，要查原始軌跡隨時查得到。

第三根，管理層：知識不流失。分析師流動不再帶走核心推論，機構的智商可以持續累積。

屋頂那四個字是最終的成果：機構信任度。

三根柱子少一根，這個屋頂都撐不住。

這一頁只有一個問題，但請務必帶回公司問一次。

您們過去半年發出去的內容，有多少句追得回依據？

不必精確，估個比例就好。

多數機構第一次估完，自己會嚇一跳。

底下那句話請記住：在這一行，追得回依據不只是效率，是絕對的風險控制。

最後是三個步驟。

步驟一，盤點現狀，看看會議紀錄與報告目前怎麼保存。

步驟二，選擇痛點，找出最常被要求補依據的那一個產業組。

步驟三，界定範圍，一起評估導入的規模與目標，小規模先試做一個。

畫面最底下那段聲明要念清楚：這套系統是內部的知識管理工具，不產生也不構成投資建議，不能取代法令要求的合規審查程序。

數字是合理預期，不是實測保證值。

聯絡方式就在畫面上。

這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 24 保險經紀與代理

客戶問理賠範圍，業務員怕冷場，憑記憶說了一句「這個情況應該有賠啦」；三個月後出險才發現客戶投保的是舊版、他記成免等待期的新版，公司賠付息事寧人，而主管根本查不出這句話對多少客戶講過。這一集示範怎麼在客戶面前三十秒調出帶條款出處的答案，以及為什麼這套系統被刻意設計成「敢說我不知道」——在保險業，一句誠實的「查無依據」比一句漂亮的猜測值錢得多。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進保險經紀與代理。

畫面上這五個字，是這一行每天都在發生的關鍵時刻：這句話賠不賠？

請注意主標的寫法——它問的不是「這個理賠賠不賠」，是「這句話賠不賠」。

差別在哪？因為業務員在客戶面前講出口的那一句，本身就是承諾。

副標把整集的目標寫完了：把風險賭注，轉化為專業護城河。

今天我們就來看，怎麼把「賭」變成「有依據」。

我們看一條時間軸。

時間零，銷售當下。

客戶問理賠範圍，業務員怕冷場，憑著記憶說出那句致命的承諾：這個情況應該有賠啦。

請注意「應該」兩個字。

那一刻他其實沒有把握，但當場說「我回去查」會冷場。

三個月後，出險理賠。

客戶投保的是舊版，業務員記成的是免等待期的新版。

條款上一個很小的落差，理賠遭拒。

再往後，就是管理層的黑洞。

公司賠付息事寧人，業務員面臨扣發獎金。

但最大的痛點在第三行：主管沒有辦法稽核，這位業務員對其他客戶講過幾次同樣的話。

畫面最底下這句話，請經營者記住：這一行的風險不在賣不出去，而在賣出去的時候講錯了什麼。

為什麼記不住？

畫面上四格，標題已經先講了：這不是態度問題，是系統性困境。

左上，情境與要件的落差。

客戶問的是「我媽媽這個狀況賠不賠」，那是情境；條款寫的是定義與除外責任，那是要件。

中間這一層翻譯，本來就要靠人腦完成。

右上，商品數量遠超記憶容量。

十幾家公司乘上百張商品，再乘新舊制，再乘各種批註。

這個量沒有人記得住。

左下，這一格最誠實：業務誘因與謹慎背道而馳。

當場說「回去查」會冷場，說「應該有」能促成交易，而錯誤的代價要三個月後才浮現。

右下，差異藏在細節裡。

商品名稱長得很像，賠與不賠只有一線之隔——例如等待期三十天，跟不含特定既往症。

所以方向要換。

畫面上這個翹翹板，左低右高。

左邊那一端是過去的妥協：依賴人腦記憶，用猜測承擔風險。

右邊那一端是未來的護城河：在客戶面前的三十秒內，當場調閱帶出處的精確解答。

請注意「三十秒」跟「當場」這兩個詞。

晚一天給答案，客戶已經簽別家了。

畫面最底下那句話是整集的樞紐：問題的核心不是要求兩百個業務員把上千張條款背得更熟，而是能不能打造一條把資料轉化為知識的產線。

把它讀成一句話就是——不要跟人腦比記憶力，那是必輸的。

那條產線長什麼樣？

畫面上三段。

左邊是原料匯入，四種：商品條款、比較表與爭議案例、核保理賠的問答，還有教育訓練錄影的逐字稿。

請特別注意第二項跟第四項。

爭議案例是最貴的原料，因為那是真的出過事才留下來的；教育訓練錄影則通常放在硬碟裡沒人回去看。

中間是清洗程序：去贅字、把客戶姓名這類敏感資訊蓋掉、分類貼標籤、提煉核心摘要。

右邊是結構知識網，蒸餾成一頁一頁互相連結的概念頁，隨時準備被精準查到。

這四類原料每一家保經代公司都有，差別只在於它們現在還是原料。

實際在客戶面前是什麼樣子？

畫面上是一段對話。

業務員問：這張的門診手術賠不賠？

系統回：該商品以住院為給付要件，門診手術不在給付範圍。

底下還多給了一段：另外注意，等待期依投保年度而異，舊制版本三十日，新制版本已經取消。

請看這一段——它就是第二頁那場災難的解藥。

業務員沒有問等待期，但系統主動提醒了。

最底下那一行是出處：健康險商品條款第十二條，加上二〇二三年商品說明會錄影。

右邊那句註解說得很好：不再憑空承諾，讓業務員講出的每一句話，背後都有堅實的依據。

不過在這一行，準確度還不是最高標準。

這一頁講的才是。

畫面左邊，是人工智慧最大的致命傷：編造一個聽起來很專業的答案。

底下那個等式很嚇人，但完全正確：在保險業，一句編出來的話等於一張保單，等於一次拒賠，等於一件申訴。

畫面右邊是核心鐵則，只有五個字：敢說我不知道。

系統設計的方向是寧可不答，也不亂答。

請注意，這句話的意思是它會刻意犧牲一部分「答得出來的比率」，去換取「答出來的都是對的」。

在別的行業這樣做也許太保守，在保險業，這是唯一能走的路。

那「不知道」是怎麼判斷出來的？

畫面上這張流程圖有兩道門檻。

業務員輸入問題之後，第一道門檻問：撈出來的內容跟問題的相似度達不達標？

不達標就擋下來，系統不硬湊。

通過第一道之後，還有第二道門檻：撈出來的這些內容，有沒有直接回答到這個問題？

這一道很關鍵——有時候撈到的東西確實相關，但它只是講到旁邊，並沒有回答。

這時候一樣擋掉，不盲目推論。

兩道都沒過，輸出的就是那四個字：查無依據。

右邊那段話請一定要看：在保險業，查無依據是安全的答案。

而且它會引導業務員做出正確的動作——回去問核保或理賠單位。

一句誠實的「查無依據」，比一句漂亮的猜測值錢太多了。

這一頁講邊界，畫面上是兩個交疊的圓。

左邊那個圓是系統的守備範圍：知識管理與條款調閱。

它回答的是「條款怎麼寫」，提供的是客觀依據。

右邊那個圓是專業人員的權責邊界：個案的核保與理賠判斷。

判斷「這件案子賠不賠」需要考量具體病歷跟個案細節，這件事必須由權責單位來做。

兩個圓有一小塊交疊，但絕大部分是分開的。

畫面最底下那一行請念清楚：界線分明——系統不提供保險商品建議，絕不越權代替理賠判斷。

所以第六頁那個回答，講的是「條款寫的是以住院為給付要件」，不是「您這件不會賠」。

這兩句話差很多。

這套機制同時保護兩種人，畫面左右各一邊。

左邊是對內，管理層的保護：誰問了什麼、系統回了什麼，完整留存。

一旦發生爭議，有據可查——這正好補上第二頁那個黑洞：主管終於查得出來，這句話對幾位客戶講過。

右邊是對外，業務員的保護：每個答案都可以一鍵點開看條款原文。

業務員可以自己再確認一次，甚至直接把原文拿給客戶看。

這一點在銷售現場非常有力量。

客戶看到的不是業務員的說法，是白紙黑字的條款——專業感是這樣建立的，溝通落差也是這樣消掉的。

導入前後的對照，畫面上四列。

第一列，面對提問的當下。

從賭一把說「應該有」、或者說「回去查」造成冷場，變成當場查完自信地說：這張是住院才賠，我把條款給您看。

第二列，查詢耗時：從數十分鐘翻找各家條款，縮短到數分鐘內。

第三列，潛在風險：沒有依據的承諾大幅減少，而且新人可以獨立說明的商品數提高。

第四列是最有價值的一列：同樣一個問題，從「在賭」變成「展現專業」。

請注意，客戶問的問題完全沒有變，業務員的能力也沒有一夜之間變強。

變的是他手上有沒有依據。

另外提醒，這些是導入目標與合理預期，不是實測保證值。

最後這一頁是一座冰山。

浮在水面上的是可見成本：三個月後的幾件客訴與罰款、主管機關的關注、通路信任的流失。

這些算得出來。

水面下那一大塊是隱藏風險：您們兩百位業務員，這個月講出去無數句沒有依據的話。

這些話多數不會出事，但您不知道是哪幾句會。

右邊有兩個可以先想的問題：哪一類商品最常被講錯？教育訓練與爭議案例目前怎麼保存？

從最常被講錯的那一類開始做，效果最明顯。

畫面最底下那行小字也要念：本集情境與數據是導入目標的合理預期，系統是知識管理工具，不作為核保或理賠的判斷依據。

聯絡方式就在畫面上。

這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 23 銀行與金融機構

同一項業務，客戶跑兩家分行拿到兩種答案：A 分行依作業主規章說要補件，B 分行依後來的放寬通報說不用——調查結論是沒有人惡意、兩位行員都有依據，問題出在規章之間的關係沒有人有全貌。這一集示範怎麼讓六十家分行問同一句話得到同一個附出處的答案，以及一件事後才顯出價值的事：查詢紀錄讓稽核報告從「解釋人為疏失」變成「證明依據一致」。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進銀行與金融機構。畫面上這一句是這一集的目標：終結櫃檯前的資訊迷宮。副標更具體——從兩千份規章，到單一事實來源。您看畫面上那些發散的線，全部收束到中央那一顆金色的多面體。那就是這一集要做的事：規定不必變少，但答案要只有一個。

我們從一件客戶申訴看起。同一項業務，客戶跑了兩家分行，得到兩種答案。A 分行說：這項業務需要補件。他的依據是銀行的作業主規章。B 分行說：這項業務不需要補件。他的依據是後來發布的一份放寬通報。問題在括號裡那半句——那份放寬通報，其實不符合這個案子的適用條件。底下的調查結論寫得很清楚：沒有人惡意，兩位行員都有依據。問題出在規章之間的關係，沒有人有全貌。請注意，這不是有人偷懶或亂講。兩個人都很認真地查了，也都查到了東西——只是各查到一半。而客戶感受到的是什麼？不是「兩位行員理解不同」，是「這家銀行說話不算話」。同一家銀行，兩種標準，這比補不補件嚴重得多。

為什麼一定會用錯？畫面上四格，標題已經先講了：這不是人員訓練問題。左上，數量超載。超過兩千份文件，每年數百件異動。這個量，完全超出人腦的負荷。右上，複雜交錯。規章互相引用、互相修正，有時候要四份文件疊在一起，才看得出實際適用的是哪一版。左下，時間斷層。這一格最致命：櫃檯前只有三分鐘可以做決策，但正確查完所有關聯規定需要二十分鐘。三分鐘跟二十分鐘之間那個缺口，就是所有分歧的來源。行員只能在缺口裡憑經驗補上，而每個人的經驗都不一樣。右下，缺乏軌跡。事後沒辦法重建當時問了誰、依據什麼，只能靠人員回憶。所以再加強訓練，也補不上這四格。

這一頁只有一句話，但它是整集的核心，而且出自稽核報告。本案非規章不備，而係規章可及性不足。用白話講就是：不是我們少寫了規定，是行員在需要的時候拿不到它。畫面最底下那一行把它講得更白：規定不缺，缺的是在櫃檯那三分鐘裡，找得到正確的那一條。這個轉向很重要。因為這兩種診斷，會導向完全不同的處方。如果診斷是「規章不備」，那接下來就是再發一份規定、再開一場宣導會。如果診斷是「可及性不足」，那要處理的是三分鐘裡拿不拿得到——這是兩件事。過去二十年，多數金融機構走的都是第一條路：出事就再發一份規定。於是文件從一千份變成兩千份，而可及性反而更差。

那要怎麼提高可及性？畫面上這條產線，四個區。第一，原料區：作業規章、通報、函令，還有常見問答，全部匯進來。第二，清洗區：去掉贅字，把客戶姓名帳號這類敏感資訊蓋掉，分類貼標籤，抓出核心摘要。第三，蒸餾區。這一區是這一集最關鍵的一步——它要理清規章之間的修訂關係。還記得第二頁那兩位行員嗎？他們缺的就是這個關係。第四，輸出區：單一事實來源，一句話問得到，而且附帶精準的出處。標題那句話值得再念一次：這不是雲端硬碟，也不是把檔案丟給人工智慧。差別就在中間那兩區。

實際問一句話會怎麼樣？畫面上方是櫃檯的提問：這項業務可以免附那份文件嗎？左邊是過去：耗時二十分鐘，要翻三份通報、兩份規章。風險寫在下面——極容易遺漏前提條件，導致決策分歧。右邊是現在：耗時數秒鐘。系統的判定是：原則上仍然應該檢附；只有在同時符合三項條件的時候，才可以適用簡化措施；任何一項條件不符，就要依原作業規章辦理。請注意「任一條件不符」這半句——這正是第二頁 B 分行漏掉的東西。底下還附了精準出處：某某通報、某某作業規章第幾條。標題那句話是重點：讓六十家分行問同一句話的時候，得到完全一致的答案。

接下來這一頁，是金融業跟其他行業最不一樣的地方。標題寫得很直接：光查得到不夠，還要查得到查詢紀錄。畫面中間那張表，每一列就是一次查詢。四個箭頭指出四件被記下來的事。左上，誰在什麼時間提問。右上，提問的完整內容——注意是完整內容，不是摘要。左下，系統引用的具體段落。右下，來自哪一份規章或通報。最底下那一列還記了使用的模型與用量歸屬。為什麼要記到這種程度？因為在金融業，事後說不清楚，跟當下做錯了，責任幾乎是一樣的。主管機關要看的從來不只是結果，還有您怎麼得到這個結果。有紀錄，這一題就有答案。

那些紀錄留下來能做什麼？畫面上三張防護網。第一張，事後重建判斷。客訴發生的時候，可以精準還原當時系統給的是什麼依據。不靠個人回憶，用數據證明合規性——這一句對法遵單位的價值非常高。第二張，規章體檢表。這一張是意外的收穫：反覆被問的問題，還有回覆「查無依據」的問題，其實就是規章的盲區，或者是還沒匯進來的破口。換句話說，系統答不出來的地方，正好告訴您管理上該補哪裡。第三張，成本與用量可視化。各單位用了多少、成本歸在哪裡都抓得出來，數位轉型的投資成效才看得見。

這一頁講邊界，三件事一定要先說明白。第一，紀錄全透明。問答內容會被完整保留，所以使用者必須事先知道這件事。在金融這種高度紀錄的環境裡，這是常態，但一定要先講。第二，寧缺勿濫。當相似度不足的時候，系統直接回「查無依據」，絕不硬湊一個答案。在這一行，一個聽起來很專業的錯誤答案，比一句「查不到」危險太多了。第三，這一條最重要：它不是自動法遵系統。系統不會自動偵測外部法規異動。新舊函令與內規的上下架，還是要依賴內部的標準流程。換句話說，它讓您查得到，但沒有人上架，它就查不到。這一句一定要在導入前講清楚。所以導入的時候，一定要指定一個單位負責規章的上下架。這是管理職責，不是系統功能。

導入之後最大的改變在哪裡？答案不在櫃檯，在稽核報告。畫面左邊是過去：我們必須耗時重建判斷過程，最終只能向主管機關解釋——這是規章可及性不足導致的人為疏失。這段話翻成白話就是：我們自己也說不清楚，只好認了。畫面右邊是現在：我們只需要調出系統紀錄，直接證明該行員引用的依據與系統答覆完全一致，而且符合當時的規章。兩段話的差別，是「解釋」跟「證明」。畫面最底下那句話總結得很好：導入的效益不只是查找縮短到數分鐘、新人養成期縮短，更是把管理盲區，變成一條可以證明的合規防線。

這一頁是給管理層的，畫面上是一個會越轉越快的飛輪。先看左邊那個提問：您們兩千份規章，行員實際上用得到幾份？這個問題過去沒有人答得出來。現在透過查詢紀錄，銀行第一次擁有這個數據。右邊那個循環轉三步：第一，累積查詢數據；第二，發現盲區；第三，規章整併與優化。整併之後，查詢會更準，數據又更清楚，於是越轉越好。畫面最底下那個比喻很傳神：系統不只是查找工具，更是組織知識的 X 光機。它照出來的東西可以直接拿去指導兩件事：規章要整併哪些，教育訓練要加強哪裡。以前這兩件事靠的是各單位反映跟主管的感覺，現在靠的是六十家分行實際問過的紀錄。

最後這一頁，是一個很好的起點問題：從哪一類最常出現答覆不一致的業務開始？不必一次把兩千份規章全部匯進來。挑一類，做出來，數字就會說話。畫面最底下那行小字也要念清楚：本集情境取材自示範案例，數字是導入目標與合理預期，不是實測保證值。另外請特別記住——這套系統是知識管理工具，不是法規遵循系統，也不提供法律或法遵意見。它負責的只有一件事：讓正確的那一條，在櫃檯那三分鐘裡拿得到。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 22 資訊委外與MSP

資深工程師請了一週婚假，週二客戶A斷線、週四客戶B郵件寄不出去、週五客戶C誤刪檔案救援判錯——三次都不是技術能力不足，是三件「只有那個人知道」的事，多耗十一小時，換來客戶一句「怎麼換個人來就什麼都不知道」。這一集示範怎麼讓代班的人當場問出這家客戶的真實現況，以及為什麼「無權限查看」這句話在維運業是洩密：您手上握著的，是好幾家同業競爭者的網路架構。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進資訊委外與維運服務商。畫面上這個問句，是這一行最不敢承認的事實：客戶的機房長什麼樣，只有一個工程師知道。副標把整集的目標講完了——從賣個人的記憶，到賣公司的服務水準。右邊那張圖有幾十櫃設備，只有一櫃被標成橘色。那一櫃就是有人真的清楚的部分，其他都是灰的。這一集要做的，就是把灰的變成橘的。

我們看一位資深工程師請了一週婚假，這一週發生了什麼。週二，客戶 A 網路連線斷了。代班的人不知道防火牆的管理埠已經被改過，也不知道那套備援要手動切換。週四，客戶 B 郵件寄不出去。代班的人不知道這個環境的郵件是走外部轉送的，設定在另一家供應商那裡。週五，客戶 C 誤刪檔案要救援。代班的人不知道這家客戶曾經要求縮短備份的保留天數，照著舊文件判斷，結果判錯了。右下角那一格是總帳：時間多耗了十一個小時。但底下那一句才真的傷：怎麼換個人來就什麼都不知道？請注意，三次都不是技術能力不足。是三件「只有那個人知道」的事。

這一頁把矛盾攤開來講。畫面左邊是一份合約，白紙黑字：您們簽的是服務水準。畫面右邊是一顆腦袋，裡面糾纏著一堆線：但實際交付的，是「某個人記得」。中間那道裂縫，就是這一行的風險所在。底下那段話請經營者念一次：您賣的是不中斷的服務水準，但當三十八家客戶的環境知識全綁在少數幾位工程師身上，公司的商業承諾就是一個極度脆弱的單點故障。合約承諾的是公司，實際交付的是個人。這中間的落差，平常看不出來，只有那個人休假的時候會看出來。

那把文件寫完整不就好了？畫面上四格，說明為什麼這條路走不通。左上，活環境對死文件。建置文件停在上線那一天，往後三年每一次擴充、每一次規則異動，幾乎都不會回寫。右上，暫時變成永久。這一格最真實——「先這樣繞過去」的應急設定，佔掉大半排障時間，而這些動作幾乎從不上件。左下，知識的形狀是對話。派工單上只寫「已處理完成」，真正的技術細節，藏在現場跟客戶口頭說明的那五分鐘裡。右下，認知過載。三十八家客戶乘上每家幾十項設定，人腦記不住，於是必然形成「這家是誰負責」的孤島分工。所以要求大家把文件寫完整，方向本身就錯了。

那問題要怎麼重新問？畫面上左右對照。左邊打叉的是舊思維，畫面上叫它無效抗爭：怎麼逼工程師把維護文件寫得更完整？這個問法，十年來沒有一家公司成功過。右邊打勾的是新思維：代班人員接手的時候，能不能隨時「問」出這家客戶的真實現況？差別在哪？左邊要求人多做事，右邊只要求把已經產生的東西留住。底下那句話講得很清楚：我們需要的不是另一個雲端硬碟，而是一條把混沌原料提煉成可查詢知識的自動化產線。雲端硬碟您們早就有了，問題從來不是沒地方放。

這條產線分三段。第一段，混沌投入。請注意第一句話：每一個客戶擁有獨立的盒子。這一點在維運這一行是底線，等一下第八頁會再講。要放進去的東西：建置文件、架構圖、派工單、變更紀錄，還有現場處理的口頭錄音。最後那一項是關鍵。工程師在客戶端講的那五分鐘，錄下來就進得了系統，不必請他回來再寫一次。第二段，清洗與萃取：去掉贅字，把客戶主機的位址、帳號、憑證這些敏感資訊強制蓋掉，然後做語意分類與脈絡摘要。第三段，蒸餾成一頁一頁有上下文、而且互相連得起來的概念頁面。從碎片，變成資產。中間差的就是這條產線。

回到週二那一通電話，如果有這套系統會怎麼樣？畫面左上角先注意一件事：目前檢視的盒子是客戶 A。先選對盒子，才問問題。代班工程師問：這家連線斷線要怎麼查？系統回的是這一段：該客戶防火牆是兩台備援，但需要手動切換，切換的時候必須同步規則；管理埠已經改成非預設埠。連線帳號跟網域服務整合，網域伺服器是老舊主機，避免非必要重啟。這四句話，就是週二那位代班者缺的全部。底下還附了出處：某某客戶現場處理錄音的逐字稿，加上歷次派工單。右邊那行直式的字是這一頁的結論：交付的不再是一份死文件，而是一個換誰接手都能精準應答現況的戰情中樞。

接下來這一頁，是維運服務商最該看的一頁。您們手上握著的，是很多家公司的網路架構與弱點紀錄——而這些公司之間，很可能是同業競爭者。畫面上半是一般系統的做法：沒有權限的時候顯示「無權限查看」。底下那行紅字寫出了致命傷：這句話等於告訴這位工程師，這家客戶的這份機密資料存在。畫面下半是本系統的做法：權限的過濾做在查找那一層，沒有權限的人搜尋，直接顯示查無資料。底下寫著護城河——完美隱匿，連「我們有服務這家客戶」的跡象都不會洩漏。差別聽起來很小，但在這一行是天差地遠。權限做在畫面上是遮住，做在查找層才是真的沒有。

光有隔離還不夠，實務上還要三道護欄。第一道，強制清洗。客戶主機的位址、帳號、憑證、序號，在進入知識庫之前一律蓋掉。嚴格規則寫在下面：處理沒有正確完成，整筆退回重跑。不是盡量遮，是不乾淨絕對不放行。第二道，臨時授權。代班期間才把人動態加進那個客戶的團隊，代班結束就移除。規則是：留存完整的稽核紀錄，事後可以全盤追溯誰、在什麼時候、看了什麼。第三道，物理根除。這一道是給合約終止、客戶離場用的。規則是：刪除整個知識來源，把清洗後的內容跟問答一起銷毀，確保完全符合離場的合規流程。第三道最容易被忽略，但它是您在提案時最有說服力的一句話——客戶會問「我們如果不續約，資料怎麼辦」。

導入之後，同樣一個代班週會變成什麼樣子？畫面上四格。左上，突發排障的時間落差。導入前明顯延長，導入後跟正常維運的落差大幅縮小。右上，打擾原負責人的次數，下降六成以上。這一格請特別看重——它的意思是，那位資深工程師終於可以真的放假了。左下，新進工程師的戰力。從只能從旁打雜，變成可以獨立處理的客戶數顯著提高。右下是客戶真實的感受轉換。以前是：怎麼換個人來就什麼都不知道？現在是：這位雖然沒來過，但他完全掌握我們這邊的狀況。這一句，就是續約的聲音。

這一頁是給老闆看的，講的是公司價值。同樣一份維運合約，左邊是過去的常態：賣的是某個人。底下四條後果：高離職風險、員工不敢休假、服務規模無法擴張、被挖角的時候損失慘重。第二條特別值得停一下——員工不敢休假，這不只是員工的問題，那是公司的營運風險寫在人身上。右邊是未來的標準：賣的是一家公司。組織級的集體記憶、無縫的人員輪替，還有最後那一條：具備規模化承接新客戶的底氣。很多維運商不是接不到案子，是不敢接。因為心裡清楚，現在的三十八家已經撐得很緊了。

最後這一頁的問題，請帶回公司數一數：您們的三十八家客戶，有幾家只有一個人清楚？右邊是三個下一步。第一，盤點最複雜、最綁人的那個客戶環境。就從最痛的那一家開始。第二，跟我們討論客戶資料的隔離架構，還有小規模先試做的範圍。隔離架構一定要先談，這是這一行的前提。第三，實際測一次：把現場紀錄轉成資產，看看代班的人問得到什麼。畫面最底下那行小字也要念：這些數字是導入目標與合理預期，實際成效取決於匯入的範圍，還有現場紀錄的習慣。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 21 軟體與SaaS公司

客戶問「匯出報表漏行是不是已知問題，我們這一版有沒有修」，答案跑過客服、客戶成功、工程三個部門，耗掉六小時——公司其實知道答案，只是走到答案的路徑太長。這一集示範怎麼把工程師寫的「位移計算錯誤」翻譯成客服敢貼給客戶的解法與替代方案，以及一條讓多數導入陣亡的生死線：答案只要需要開第二個網頁，客服就不會用。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進軟體與雲端服務公司。畫面上這個對話框，是一句每天都會出現的問題：我們遇到匯出報表時漏行，是不是已知問題？我們這一版有沒有修？客戶問得很清楚，也很合理。右下角那個橘色的標記寫著：耗時六小時。請注意標題那幾個字——不敢答。不是不知道，是不敢答。因為答錯了比不答更嚴重。這一集就來處理這六小時。

我們看這個問題實際跑過哪些地方。先看右上角的背景：一百四十家企業客戶、每兩週發一次版、同時維護三個大版本。這個組合已經注定了答案不會單純。第一站，客服部翻說明中心——沒有相關文章。第二站，客戶成功部翻發版說明——找到一條類似的，但不確定是不是同一個問題。第三站，工程部翻問題追蹤——查到了，下一個大版才修，而且不會回頭補到舊版。總歷時六小時，經手三個部門。畫面最底下那兩句最關鍵：您們公司其實知道答案，只是走到答案的路徑太長。而客戶那一句「這問題我上個月問過，怎麼又重講一次」，比技術問題本身更傷。

為什麼一定會碎？畫面上四格。左上，系統壁壘。知識天生就分散在三個系統裡，工程、客服、業務各用各的，沒有共同語言。右上，版本前提。這一格是這一行獨有的：答案永遠有前提。「修好了嗎」的正確答案，其實是「看您在哪一版」。左下，語言隔閡。工程師寫的是「位移計算錯誤」，客戶講的是「報表漏行」。這兩句話講的是同一件事，但中間需要翻譯。右下，對話揮發。這一格最可惜——某位資深客服曾經給過一段解釋得非常漂亮的回覆，但對話一結束，那段話就永遠消失了。四件事加起來，就是那六小時。

那解法是什麼？很多公司的第一反應是：要求大家多寫文章、多建說明中心。畫面左邊那一堆歪掉的資料夾，就是這條路的結局——把文件當檔案存，變成沒有人問津的數位垃圾場。為什麼失敗？因為寫文章這件事，永遠排在修問題後面。它不是不重要，是永遠不緊急。畫面右邊才是對的方向：讓散落在三個系統裡的片段答案，在客服原本的工作畫面上，被一句話問到。請注意這句話裡的兩個重點。第一，片段答案本來就存在，不必新寫。第二，是在客服原本的畫面上，不是另外一個地方。方向對了，剩下的才是技術問題。

這條產線長什麼樣？畫面從左到右。左邊那堆石頭是原料：發版說明、問題追蹤的匯出、已經解決的工單，還有技術分享的錄影逐字稿。請特別注意最後一項。技術分享錄影通常放在雲端硬碟裡，從來沒有人回去看——但裡面往往就有那段最好的解釋。中間是清洗程序，三個動作：丟掉贅字、把客戶名稱與帳號這類敏感資訊蓋掉、然後分類摘要。右邊出來的是互相連結的概念頁。副標那句話請記住：知識庫不是雲端硬碟，它是一條把原料煉成可查詢知識的精密產線。差別在於，硬碟只負責存，產線負責讓它能用。

實際翻出來是什麼樣子？這一頁左右對照。左邊是工程師原本寫的：修正匯出程式在特定分頁條件下的位移計算，狀態，四點二版已修，不回溯到三點 x 版。這段話客服看不懂，就算看懂了也不能照念給客戶聽。右邊是客服拿到的版本，分成三塊。根因：分頁的位移計算錯誤，有篩選而且跨頁的時候會發生。狀態：四點二版起已經修正，三點 x 這條版本線不回溯。解法：取消篩選後匯出，或者分批匯出。第三塊最值錢。工程師寫的內容裡沒有「解法」這一項，因為對他來說問題已經修好了；可是對還在三點 x 版的客戶來說，他今天就要交報表。最底下還附了來源依據：內部技術分享錄影十五分鐘處，加上四點二版的發版說明。

這一頁講一條生死線，很多公司就是在這裡失敗的。畫面上方那個大叉，指的是「開啟新分頁」。結論寫得毫不客氣：開啟新分頁，等於不會被使用。右邊是正解：答案必須主動出現在客服原本的工作畫面上，就像畫面裡那個貼在對話視窗旁邊的側欄。底下那句話請導入負責人一定要看：線上對話的節奏是以秒計算的，客服不會為了查資料去開第二個網頁。這件事跟系統準不準無關。再準的答案，只要多一個切換動作，實務上就等於不存在。

承接上一頁，怎麼做到「出現在原本的畫面上」？答案在這一頁。畫面正中央是知識庫的大腦，左右各拉出幾條管線，接到公司現有的工具上。左邊這條給工程師。他在寫程式的環境裡就可以直接問：這問題之前怎麼解的？不用離開開發環境。右邊這條給客服與業務，接進對話介面、內部通訊軟體，答案直接跳在他們每天在用的視窗裡。請注意右邊那條管線上寫的是唯讀——只能查，不能改。這一點很重要，開放是為了查得到，不是把知識庫變成大家都能亂寫的地方。知識庫不必是一個大家要「去」的地方，它應該是一個隨處都在的東西。

開放之後會不會失控？畫面上四根柱子就是在回答這件事。第一根，權限跟著走。權限是綁在團隊上的，而且金鑰可以隨時更換。換一個入口進來，一樣受同樣的限制，不會因為換了工具就繞過去。第二根，出處必帶。每個答案一定附上原始文件的連結，客服看得懂依據才回覆客戶。這一條在這一行特別重要——客服如果只拿到一句結論，他不敢貼給客戶。第三根，用量透明。每一筆查詢用了多少、是誰用的，都有紀錄，成本與使用頻率抓得出來。第四根，自主匯入。系統不會主動去讀您的資料，要放什麼進來完全由企業自己決定。四根柱子加起來，就是「開放但不失控」這六個字。

同一次客訴，兩種平行時空。畫面上三列。第一列，等待時間：從六小時，變成幾秒鐘，而且是在同一次對話裡解決。第二列，跨部門交接：從三次以上，變成零次。首次回應就解決的比率會明顯提高。第三列最重要，是客戶真實的感受。過去聽到的是：這個我幫您確認一下，稍後回覆。客戶心裡的解讀是——他們好像沒有人知道答案。現在聽到的是：這是已知問題，替代方案如下。客戶的感受是——他們早就準備好了。同樣一個還沒修好的問題，客戶的感受可以完全相反。差別不在有沒有修，在於您答得出來還是答不出來。

這一頁是給經營者算帳的。畫面左邊那個數字是一百四十，也就是客戶數。右邊那個提問是：同一個問題，重複問過幾次？底下那句話說得很含蓄：歷史紀錄通常會讓人嚇一跳。右邊那個翹翹板講的是兩種成本。一邊，每一次重複回答，都是白花的人力成本。這一邊算得出來，但通常不算大。另一邊，每一次回答不一致，都是品牌信任的耗損。這一邊算不出來，但它才是真正壓垮續約的東西。同一個問題，兩位客服給了兩種答案——客戶不會覺得是溝通問題，他會覺得這家公司對自己的產品不夠清楚。

最後這一頁，是開始的三步。第一步，盤點現狀，看看發版說明、問題追蹤與工單，目前怎麼保存。第二步，找出痛點。從歷史紀錄裡撈出最高頻重複的那幾個技術問題——這一步通常最有說服力，因為數字會自己說話。第三步，選一條產品線試點，小規模先試做一個。底下那句話講得很好：一起打造屬於您的零摩擦知識工作流。零摩擦這三個字，就是前面第七頁那條生死線。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 20 系統整合商

手冊寫著「點擊批次過帳按鈕」，客戶說這個功能我們這邊沒有——那顆按鈕三年前就為了配合客戶的簽核流程移掉了，客製紀錄停在兩年前，當初維護的人已經轉調，一通電話耗掉五十分鐘還是沒有答案。這一集示範怎麼把「二十個客戶二十種真相」拆成二十個互不污染的盒子，以及一個不會報錯、所以沒有人發現的陷阱：文件塞太多時，系統會安靜地把後半段截斷。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進系統整合商。畫面正中央那一塊寫著「核心產品」，四周是二十個盒子——每一個都裝著一點不一樣的東西。主標寫得很直白：一套系統，二十個客戶，二十種真相。底下那兩句話才是真正的痛：您們的產品只有一個名字，但實際上有二十個版本，而且沒有一份文件說得清楚差異在哪裡。這一集要解的，就是這件事。

我們看一通很典型的客服電話。畫面左邊是標準操作手冊：步驟一登入系統、步驟二選擇財務管理、步驟三點擊批次過帳按鈕。客戶在電話那頭說：這個功能我們這邊沒有。右邊就是客戶真實的畫面，那個按鈕的位置是空的。接下來會發生的事，各位應該都很熟悉：工程師開始翻文件、翻對話紀錄，五十分鐘過去，還是沒有答案。底下這兩格才是真相。客製紀錄最後更新在兩年前；而那個按鈕，其實三年前就為了配合客戶的簽核流程被移掉了，當時負責維護的人已經轉調。所以那五十分鐘不是慢，是完全無效——因為手冊講的，跟客戶那一套根本不是同一個東西。

這一頁點出了整個產業最貴的一筆帳。畫面上方那台整齊的機櫃，是程式碼與標準架構。這一塊其實管得不錯——有版控、有規範、有審查。真正的黑洞在下面那一層：哪個客戶到底裝了什麼。您看那些糾纏的線、貼滿的紙條、散落的資料夾，就是這一層的實況。畫面最底下那句話請記住：問題不在於工程師懶不懶惰，而是接聽電話的當下，能不能在三十秒內查到這一家客戶的實際狀況。三十秒，是這一集的標準。查得到，是專業；查不到，客戶感受到的就是「你們自己也不清楚」。

為什麼會崩塌？畫面上四個維度。左上，時間斷層。客製是在專案期發生的，但文件停在交付日。上線之後那三年的修補、欄位加掛，從來不會回寫進規格書。右上，詞彙分歧。同一個名詞，各家講的不是同一件事。批次過帳，在 A 客戶是三段簽核，在 B 客戶是排程，在 C 客戶已經移除了。左下，組合爆炸。客戶乘上版本、乘上資料庫、乘上部署環境、乘上模組，等於幾百種組合。所以那份總表，三個月內必定過期。右下，知識屬人。「這家是誰做的」是目前最有效的查詢方式，但它同時也是最脆弱的單點故障——那個人請假、離職，整條線就斷了。

那把所有文件丟給人工智慧，讓它自己找，不就好了？這一頁講為什麼這樣做注定失敗。右邊三條。第一，語意比對不等於條件過濾。「某某公司」這幾個字，會出現在比較文件、共用範本，甚至郵件副本裡。您想問 A 客戶，撈回來的卻是一堆提到 A 客戶的別人家文件。第二，中文斷詞陷阱。系統型號，例如 MC-200A，常常被切成幾個沒有意義的片段，比對的時候完全失去識別力。第三，權重覆蓋。關鍵字比對的分數是有上限的，很容易被其他客戶「語意相近但不適用」的段落蓋過去。結論是：在這一行，不精準等於有害。答錯一個客製設定，比答不出來更糟。

所以做法要換一個方向。畫面上是一整排貼著客戶名稱的盒子。副標把重點講完了：您需要的不是一份永遠追不上的客製總表，而是二十個各自獨立、互不干擾的盒子。右邊兩個原則。第一，單一真相：一個客戶等於一個知識來源盒子。問 A 客戶的事，就只在 A 的盒子裡找。第二，封閉上下文：規格書、客製紀錄、交接錄音，全部鎖在同一個環境裡，絕不跨客戶污染。這個轉向很重要——過去我們想的是「怎麼把資料整理成一張大表」，現在想的是「怎麼讓每一家的資料誰都干擾不到誰」。隔離，本身就是準確度。

盒子裡面放什麼？這條產線給了答案。左邊叫原始廢料，其實一點都不廢：規格書、變更單，還有交接會議的逐字稿。特別是最後這一項。交接會議通常只留下一份簡單的紀錄，可是真正的資訊都在對話裡——那些「這家比較特別，他們的簽核是三段」就是在那時候講的。中間是清洗程序：自動去掉贅字，把帳號密碼、客戶主機位址這類敏感資訊蓋掉，然後分類與摘要。右邊是蒸餾，變成可以互相連結、即時查詢的概念頁面。從廢氣到燃料，這個比喻很貼切。這些東西您們本來就有，只是一直當廢料在堆。

用法只有一條黃金法則，就在這一頁。第一步：先選盒子。畫面上是選擇知識來源，客戶 A 的現況。第二步：再問問題。這家的批次過帳怎麼操作？順序不能顛倒。很多人習慣先問問題，再用勾標籤去縮小範圍——這在這套系統裡是無效的。因為底下這句話：分類多選是「或」，不是「且」。您勾越多，撈進來的越多。分類是用來找得到，不是用來鎖得住。只有預先限定來源，才能在二十個版本並存的情況下，保證答案是這一家的。

把兩種架構並排比，差別會更清楚。第一列，查找的邏輯。左邊是把二十家的資料混進同一個大池子，再靠提示詞去限制範圍——畫面上寫得很誠實：容易失敗。右邊是物理隔離，只在指定的那一份資料裡找。第二列，答錯的風險。左邊極高，A 客戶的設定很容易污染到 B 客戶的回答。右邊是零跨界污染——因為那個盒子裡根本沒有別家的資料可以混淆。第三列，適用情境。這一列很重要：左邊那種做法不是不能用，通用型的知識，例如標準安裝手冊，用大池子完全沒問題。但高度客製化的專案支援與維護，一定要分盒。一家公司兩種都會用到，重點是不要用錯地方。

分好盒子還不夠，盒子裡面也要有紀律。這一頁講兩件事。第一，命名的一致性。錯誤示範是「客戶 A 資料」——這個名字什麼線索都沒給。正確做法是「客戶 A - 製造管理系統 - 現況」。來源的標題本身就是判讀的線索。第二件事更隱蔽，畫面上叫靜默截斷。一個盒子如果塞進三年份、上百份文件，很容易撞到模型能處理的上限。這時候系統不會報錯，它只會安靜地截斷。您得到的答案看起來完整、語氣也很肯定，但其實後面那一段根本沒被讀到。解法是依主題往下分層，例如拆成現況、變更歷程、教育訓練，然後定期抽查尾段的內容有沒有被讀進去。這一條沒有人會提醒您，因為它不會報錯。

同樣一通電話，導入前後差在哪？左邊是導入前：我確認一下您那邊的版本，可能要問一下當初做這個案子的同事，晚點回覆您。底下的註解很傷人，但很真實——耗時數十分鐘甚至數天，聽起來像個不熟這套系統的陌生人。右邊是導入後：您那邊的批次過帳是三段簽核完成後自動觸發的，不需要手動點擊。另外提醒，明細表有兩個客製欄位，升版前要先確認相容性。括號裡還附了出處：交接錄音第九分鐘。耗時三十秒，聽起來像每天都在用這套系統的專屬顧問。請注意右邊多講了一句「升版前要確認相容性」——那是客戶沒問，但您主動提醒的。這一句，就是續約的來源。

這一頁是給經營者的。畫面左邊那張圖有兩條線。往上走的那條是知識管理，時間越久越有價值；往下掉的那條是單點依賴——它一開始很有效，但掉得非常快。右邊那個問題，請帶回公司問一次：您們的二十家客戶，有幾家的現況只有「那一個人」清楚？底下那段話講得很到位：在這一行，每一次人員異動就是一次服務品質的斷崖。知識管理不只是為了省客服工時，它直接決定了公司的營運韌性，也決定了您有沒有底氣去簽下第二十一家客戶。很多整合商不是接不到案子，是不敢接——因為心裡清楚，現有的二十家已經撐得很勉強了。

最後這一頁講怎麼開始，三步。第一步，盤點。看看現有的客製紀錄、交接會議與變更單，目前保存到什麼狀態。第二步，試點。這一步的挑法很特別——挑目前現況最模糊的那一家客戶。一般人會想先挑最單純的來試，但最模糊的那一家做出來，全公司才會相信這件事有用。第三步，建盒。確立導入的範圍，小規模先試做一個，打造出第一個標準盒子。第一個盒子建好，後面十九個就是複製同一套做法。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 19 廣告與行銷代理商

新人到職兩週，提案被退三次：語氣太活潑、食品情境不能用這個顏色、法務禁用「第一」——三件事沒有一件寫在那本八十頁的品牌手冊裡，知道的是三個不同的人，其中一位還在放產假。這一集示範怎麼把群組裡夾著情緒與閒聊的抱怨，提煉成附出處的禁忌指南，以及為什麼「摘要重點」這個要求本身，就會讓知識庫變得查不出東西。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進廣告與行銷代理商。畫面上這一句，同業聽了應該心裡會抖一下：客戶的品牌規矩，沒有一條寫在提案裡。副標把價值講得很清楚——那些隱形的資產，其實決定了您的續約率。右下角還有一句：真正的資產，藏在看不見的暗礁裡。暗礁的意思是，它平常看不見，但撞上去是會沉船的。這一集就來把那些暗礁畫成海圖。

先看一個很真實的現場。新人到職兩週，提案被退了三次。第一次的理由是：語氣太活潑了，客戶的調性沒這麼跳。第二次是：食品情境不能用這個顏色。第三次是：法務禁用「第一」這種字眼。右邊那段話才是重點。這三件事，沒有一件寫在那本八十頁的品牌手冊裡。公司裡有沒有人知道？有，但他們是三個不同的人，而且其中一位還在放產假。所以新人不是不用心，他是在一片沒有海圖的水域裡開船。而且被退三次的代價不只是時間。他開始不敢下判斷，每一步都要問過主管；主管的時間也就這樣一起被吃掉了。

把剛剛那件事畫成一張圖，就是這座冰山。浮在水面上的，是那本八十頁的品牌手冊。它看得見、交接得了、也放在共用資料夾裡。水面下那一大塊，才是真正的量體：二三十條不成文的規矩。畫面上舉了三種——不能這樣寫、主管在意什麼、平台會擋什麼字。每一條都很瑣碎，但每一條都能讓一次提案被退回來。畫面最底下這句話請經營者記住：代理商真正的資產不是得獎作品，是這二三十條規矩，乘以您們所有的客戶。得獎作品掛在牆上，這些規矩裝在人的腦子裡。而且冰山還有一個特性：您沒辦法盤點它。沒有人說得出公司現在到底累積了幾條，因為從來沒有一個地方在收。

為什麼一定會斷？畫面上四格。左上，經驗來自被退稿。這一行的知識取得方式很特別——被退件才懂。沒被退過，您不會知道那個顏色不能用。右上，人員流動高、切換快，大概三年一輪。而三年，剛好是一個人開始懂客戶的時候。左下，知識分散在各個職能。企劃知道一部分、設計知道一部分、投放又知道一部分，沒有人有全貌。右下，永遠沒時間寫下來。結案就忘，因為下一個案子已經開始了。畫面最底下那句話：問題不是新人不用心，而是怎麼讓經驗可以被重複利用。這四件事，沒有一件是靠加強要求可以解決的。您要求大家結案後寫心得，第一個月會有人寫，第三個月就沒有了。因為那是額外的工，不是順路的事。

那要怎麼把它留下來？畫面上這條產線，左中右三段。左邊是混亂的日常溝通：訊息、郵件、群組裡的抱怨，全都是原料。中間這個立方體，畫面上叫它知識煉金術，就是清洗與提煉的過程。右邊出來的是可以查詢的避雷指南，包含三件事：快速找到關鍵知識、標準化的作業流程，還有經驗教訓與風險規避。畫面最底下那句話是關鍵：系統的核心價值，是把冗言贅字過濾掉，提煉出純粹的知識結晶。請注意，這一行的原料特別髒——夾雜情緒、夾雜閒聊。所以中間那一段能不能做好，決定了整件事成不成立。

我們拆一句真實的話來看。畫面上方是原始輸入：客戶今天又發飆，說什麼法務不准用最高級啦，那個「最」跟「第一」都幫我拿掉，煩死了，對了中午吃什麼？這句話裡面有情緒、有抱怨，還有中午吃什麼。經過提煉之後，出來的是畫面下方那張卡片，標題是禁用詞彙警告。規則：文案不得使用「第一」「最」等最高級用語。原因：客戶法務基於廣告不實的風險不予通過。出處：某某品牌提案檢討會錄音。請特別注意「原因」這一欄。只寫規則，新人下次還是會踩；寫了原因，他才知道哪些類似的字也要避開。還有最底下那一行出處。有出處，這條規矩就不是「聽說」——新人可以直接回去聽當時客戶是怎麼講的。一句抱怨，變成一條所有人都查得到的規矩。這就是這條產線在做的事。

不過清洗不能一套規則打天下。畫面上三個控制台，三種素材、三種調法。第一個，提案檢討。閒聊很多，所以把過濾閒聊拉高，專注抽出決策與禁忌。第二個，客戶會議。這裡剛好相反，要把保留原話拉高——因為客戶說話的語氣與用詞本身就是關鍵資訊。「盡量」跟「一定」差很多。第三個，投放成效。要把數據精準度拉高，避免系統過度歸納數值與條件，把「某某族群在某時段」歸納成「年輕人反應好」。畫面最底下那句話是給導入負責人的：代理商的素材充滿口語與情緒，清洗規則必須由您自己定義。

這一頁講兩個最常踩的坑，坑名叫「設定檔決定了知識庫的智商」。左邊，把敏感資訊蓋掉這件事沒設好會怎樣？系統會啟動防護，整批退回重跑。這是刻意的設計——寧可整批退回，也不讓半乾淨的資料放行。但它代表這份設定要由專人統一控管，不能每個人各改各的。右邊這個更常見：摘要過度籠統。如果您只要求「摘要重點」，出來的東西會抽象到查不出來——例如「客戶重視品牌調性」，這句話等於沒說。正確的做法是明確要求系統保留三種東西：條件、數字，還有禁止事項。同一批素材、同一套系統，設定檔寫得好不好，出來的東西差非常多。

導入之後的第一個月，差別在哪？畫面上三列。第一列，新人獨立產出。沒有系統的時候要數個月，而且是反覆試錯換來的；有系統之後是數週。第二列，因為不成文規範被退稿的比率。從高頻率，下降五成以上。第三列，這一列是給主管看的：資深同仁被打斷的頻率。從隨時被打斷，變成顯著降低，可以專注在核心產出。畫面上把兩邊分別叫做撞牆期跟地圖期，這個比喻很準。最底下那行小字也要念：這些數字是導入目標與合理預期，實際成效取決於設定檔的品質與匯入的資料量。

這一頁很短，但可能是整集最有用的一頁。畫面左邊，是過去主管交辦的講法：這個客戶比較龜毛，你先做一版我幫你看。底下那行小字寫得很誠實——這叫讓新人先去撞牆。畫面右邊，是導入之後的講法：這個客戶的地雷，你先去系統查一遍，做完再給我。這叫給新人一張地圖。同一位主管、同一位新人、同一個客戶，只差在一句話。但結果差很多：左邊那句話，主管要看兩三版；右邊那句話，主管只要看最後一版。畫面最底下那句話：系統改變的不只是儲存方式，是團隊協作的底層邏輯。

我們把這件事算成一個數字。畫面上是一個很簡單的乘法：十二乘以三十，等於三百六十。十二是品牌客戶數，三十是每個客戶沒有寫下來的規矩，三百六十就是潛在的未爆彈——同時也是續約的關鍵。三百六十條，沒有一條在系統裡。底下那兩句話值得念完：代理商的續約率，取決於「這家代理商懂我們」。而「懂」這件事，不該隨著人員離職而流失。客戶續約的時候，衡量的從來不是您得過幾座獎，是他要不要重新教一次。換過窗口之後那三個月，客戶要花多少力氣重講一遍——這件事，往往就決定了下一年的合約還在不在。

最後這一頁，是三個可以先想的問題。第一，您們的提案檢討與回饋，目前怎麼保存？多半是散在群組跟郵件裡。第二，哪一個客戶的默契最難傳承？通常大家心裡都有答案，而且往往就是最大的那一個。第三，規劃試點的範圍，小規模先試做一個。建議就從第二題那個客戶開始——最痛的地方做出來，團隊才會相信這件事有用。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 18 人力資源顧問與人力派遣

顧問接到一通日常諮詢，憑記憶回了一句「變形工時可以這樣排班」——那條法規一年前就改了，他剛好請假沒參加口頭發布的月會；三個月後客戶被勞檢開罰，接著是減免顧問費、賠付罰鍰、不續約，還在同業群組裡傳開。這一集示範怎麼讓每一次回答都對準現行版本、還附得出函釋出處，以及一件系統做不到、只能靠管理的事：舊版一定要被明確宣告死亡，只上傳不重跑等於沒更新。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進人資顧問與人力派遣。畫面上這個標題有個關鍵詞：風險的形狀。副標講得更白——當一句憑記憶的回答，變成企業無法承受的隱形未爆彈。您看中間那面盾牌，看起來是完整的，但外圈有三個紅點，正對著盾牌的破口。這一集要談的就是那幾個破口：在這一行，知識過期不是效率問題，是賠錢的問題。

我們看一條時間軸，從一通很普通的電話開始。時間零。一位服務三百家企業的顧問接到諮詢，憑著記憶回答：變形工時可以這樣排班。請看底下那行小字——那條法規一年前就修改過了，而這位顧問當時請假，沒有參加口頭發布的那場月會。三個月後，客戶被勞檢開罰。追溯源頭，就是三個月前顧問給的那句指導。結果是骨牌效應：減免顧問費、賠付部分罰鍰、客戶不續約，最後還在同業群組裡傳開，商譽受損。請注意，這位顧問沒有偷懶，也不是不專業。他只是剛好那天不在，而公司更新法規的方式，是「開會口頭講一次」。一個人的一天假期，換來客戶的一張罰單。這中間唯一的連結，就是那句話從頭到尾沒有一個地方可以查證。

不過剛剛那一件事，還不是最可怕的。畫面上方那個亮起來的紅點，是顯性風險：單一客戶的賠償與解約。這一筆算得出來。真正讓管理層冒冷汗的，是下面那一大片灰色的區域，畫面上叫它盲區。右邊那句話就是問題本身：同樣的錯誤答案，過去三年裡，講給幾家客戶聽過？可能是三家，也可能是三十家。畫面最底下那句結論最沉重：沒有人查得出來，因為那些對話沒有留下任何軌跡。電話講完就沒了，沒有紀錄、沒有出處，也就沒有辦法回頭盤點。這才是真正的爆炸半徑。更麻煩的是，您沒有辦法主動去補救。想通知受影響的客戶，第一步是先知道有哪些客戶——而這一步就卡住了。

為什麼一定會過期？畫面上四格，這不是員工不專業，是四個結構性的問題。左上，法規變動頻繁而且破碎。基本工資、加班費、特休、移工、職安，一年幾十處變動，而且牽動的行業各不相同。右上，更新的傳達靠口頭跟訊息。月會說明一次、群組發一則，資深的人靠記憶，那天請假的人就漏接了。左下，內部的懶人包沒有失效機制。它很好用，但也因此很危險。右下，顧問的問答沒有數位軌跡。電話一掛就消失，事後想追也追不回來。畫面最底下那句核心洞察，請經營者特別記住：問題不是顧問要更常進修，而是回答的當下，怎麼確定手上這一條是現行版本。

這一頁單獨講懶人包，因為它是辦公室裡最危險的工具。右邊三條，一條比一條嚴重。第一，過期零警示。它過期的時候，不會發出任何訊號。紙還是那張紙，檔案還是那個檔案。第二，劣幣驅逐良幣。那份常見問題一頁表因為太好用，每個人都在用——結果錯誤傳播的速度，比正確資訊還快。第三，真假難辨。共用資料夾裡的舊懶人包不會自己消失，檔名上又沒有標日期，看起來永遠都是有效的。所以懶人包本身沒有錯，錯在它沒有保存期限。食品都有標示，這一份沒有。而且越好用的那一份，傳得越廣、活得越久。第三條之所以致命，就是因為它看起來永遠都對。

所以要換一種做法。畫面左右各一種。左邊是靜態檔案庫，也就是多數公司現在的樣子：把檔案丟上雲端，或者丟給人工智慧。它的問題寫在下面——依賴檔名的慣例，沒辦法辨識內容還有沒有效，裡面充滿過期地雷。右邊是動態知識產線：把原料煉成可以查詢的知識。關鍵在那三個字：清洗、蒸餾、版本控制。尤其是最後一個。有版本控制，才能確保輸出的每一滴知識，都是現行有效的。這兩張圖的差別，其實就是「倉庫」跟「工廠」的差別。倉庫只管放，工廠管的是出去的東西能不能用。

這條產線長什麼樣？畫面上一個漏斗，分三段。第一段，匯入原料。法規條文、主管機關的函釋、內部作業指引、月會說明的錄音，還有常見問答。請注意「月會說明錄音」這一項——剛剛那位漏接的顧問，就是漏掉這個。錄下來，就補得回來。第二段，清洗程序。去掉贅字，把客戶名稱這類敏感資訊蓋掉，分類貼標籤，自動摘要。第三段，概念蒸餾。畫面上寫的是蒸餾，白話講就是再整理成一頁一個主題的知識卡，而且互相連得起來。最後變成一座隨時可以精準查詢的知識庫。請注意，這五種原料每一項貴公司本來就都有，一份也不用多產生。差別只在於它們從來沒有進過產線，所以一直是原料。

實際在諮詢現場會是什麼樣子？畫面上方是顧問打進去的問題：客戶想採變形工時，要注意什麼？底下就是系統給的指引：必須先確認這家事業單位所屬的行業是不是適用的行業，再確認已經取得工會同意；沒有工會的，要經過勞資會議同意。兩個要件缺一不可。請注意最後那一句「缺一不可」——這正是最容易漏掉的地方。再看底下那行綠色勾勾的出處：某月內部作業指引更新說明會，加上某某函釋。有出處，顧問掛電話前可以直接把依據講給客戶聽。畫面最底下那句話是這一頁的重點：您需要的不是更常辦教育訓練，而是讓科技代替大腦記住法規。

那新版怎麼進來、舊版怎麼退場？這一頁是整套系統的核心機制。畫面上兩份舊文件被蓋上大大的紅章：已汰換、已被取代。右邊那份綠色的才是現行版次。底下四步。第一步，上傳觸發。承辦人按下上傳新版本。第二步，自動標記。舊版自動標示為已被取代，不是靜靜地放在旁邊。第三步，產線重啟。系統自動重新清洗、重新整理一次，這一步不能省。第四步，軌跡保留。舊的知識還留著，因為您可能需要回溯——三個月前那個答案，當時依據的是哪一版。關鍵在第二步：舊版一定要被明確宣告死亡。沒有這一步，新舊兩版會同時被當成有效的。這也是這套做法跟共用資料夾最大的差別——資料夾裡的舊檔案不會有人幫您蓋章，它就一直躺在那裡，看起來跟新的一樣。

這一頁是誠實話，講系統的邊界。畫面最上面那行警告請一定要聽進去：「已過時」只是一個標籤，標籤的作用是讓您看得出來，不是讓它查不到。只要那份內容還在系統裡，問答還是有可能引用到它。所以底下有三條營運紀律。第一條，確實重啟產線。新版上傳之後一定要重跑清洗與整理；只上傳不重跑，等於沒更新。第二條，徹底移除根源。真正失效的內容，要整筆把知識來源移除。如果只刪掉底層那個檔案，清洗過的內容還留在系統裡，一樣會被撈出來。第三條，專人負責制。指定一個人負責版本更新。知道邊界在哪裡，才不會出第二次錯。這三條沒有一條是技術問題，全部都是管理問題。

導入前後差在哪？畫面上兩支儀表。左邊是導入前，指針在紅區：查證一件事要數十分鐘，新人沒辦法獨立作業，賠付的風險無從追溯。右邊是導入後，指針在綠區：查證時間縮到數分鐘，新人獨立作業率顯著提高，賠付風險大幅下降，而且可以追溯。但畫面最底下那句核心價值，比上面三行都重要：同樣是人為疏失，一個查不出來，一個追得到。請注意，它沒有承諾不會出錯——人一定會出錯。它改變的是出錯之後：現在所有人對著同一份現行版本回答，而且每一次查詢都有紀錄。風險的形狀，就是這樣被改變的。

最後這一頁的問題，請帶回公司問一次：您們現在，有幾份大家都在用的懶人包？底下那兩句才是重點：這個數字通常大於零。其中有幾條已經不對了？沒有人知道，因為沒有人重新查過。想聊聊的話，聯絡方式就在畫面上，也可以先小規模試做一個看看。建議從最常被問、也最常變動的那個主題開始——通常是工時或加班費，做出來馬上有感。畫面最底下那行小字要念清楚：本集的情境與數字是導入目標與合理預期，這套系統是知識管理工具，不提供法律意見。這裡是智庫引擎，我們下一集見。

30種企業知識庫應用 17 管理顧問公司

一週之內，三個專案的顧問各自花了半天，畫出骨架幾乎一模一樣的架構圖；而客戶問「你們輔導過的製造業，遇到什麼阻力」時，專案經理只答得出一句：那個是 David 做的，但他去年走了。這一集示範怎麼讓顧問為了自己方便錄下的週會，順路變成公司查得到、附得出第幾分鐘的實戰法則，以及為什麼系統整理出來的知識一定要有人核可才准進庫。

這裡是智庫引擎，專為企業設計的知識庫。本集我們走進管理顧問公司。畫面上這個標題有個很有意思的比喻：知識煉油廠。原油本身不能用，要煉過才有價值。副標點出這一集要解的題：第四十一張空白簡報。您看右邊那張圖，左半邊是一堆各自飄散的線，到了中間收束成一點，右半邊才變成整齊的結構。顧問公司缺的從來不是原料——每天開的會就是原料。缺的是把它煉成結構的那道程序。

先看畫面上方這三格。週二早上九點半、週三下午兩點十五、週四中午十一點——三個不同專案的顧問，各自花了半天，畫出骨架幾乎完全一樣的「現況痛點與改善方向」架構圖。睿衡管理顧問一年結案三十幾件，公司裡有二十二位顧問。請注意左下角那句話：沒有人偷懶，只是無從尋找。再看右下角。客戶問了一句很正常的話：你們之前輔導過的製造業，導入多久看到成效？遇到什麼阻力？專案經理心裡知道，公司至少做過五個類似的案子。但成效的數字、阻力的細節在哪裡？答案通常是這一句：那個是 David 做的，但他去年走了。這句話一講出口，這場提案的氣勢就掉了一半。客戶要的不是「我們有經驗」，是「上次那個阻力你們怎麼處理的」。畫面最底下那句話，就是顧問業最痛的一件事：顧問業賣的是經驗，但經驗每結一次案，就蒸發一次。

為什麼會這樣？畫面上四格，講的是系統設計的反作用力，不是誰不夠自律。左上，專案的封閉性。一個案子六個月，團隊三到五個人，期間累積的洞察只有這幾個人知道，結案就解散了。右上，為客戶而寫的報告。結案報告只寫結論與建議，不會寫「我們最初的假設錯在哪裡」，也不會寫「哪個部門抵抗最大」。可是請注意後面那半句——後者才是下一個案子最需要的。左下，最有價值的是說出來的。顧問一天有一半時間在開會：專案週會、客戶訪談、內部檢討，裡面全是判斷與觀察，但會後只留下幾行待辦事項。右下，高流動率是常態。顧問平均任期三年，而三年，恰好是一個顧問開始真正值錢的時候。換句話說，公司每三年就把最成熟的那一批經驗，親手送出門口。四件事加起來，結論很清楚：這不是紀律問題，是設計問題。

那要怎麼改？畫面左右兩欄，差別在四個地方。第一列，觸發點。傳統做法是結案之後額外花兩天整理；新做法的觸發點，是專案進行中本來就要開的那場會。第二列，動力來源。傳統靠顧問的紀律跟行政規範去要求；新做法是順路完成——顧問是為了自己方便才錄音的。這一列最關鍵。任何要靠自律才成立的制度，第三個月就會沒有人做。第三列，內容品質。傳統留下的是修飾過、過濾過的標準範本；新做法留下的是原始的戰術洞察，還有客戶真實的反應與阻力。第四列，結果。一個在第三個月失效、沒有人維護；一個順手把每一場會議，變成公司的長期資產。

實際怎麼運作？畫面從左邊看起。輸入端是一場九十分鐘的專案週會，顧問為了自己方便錄下來的。進來以後先做語音轉譯與清洗，自動變成逐字稿。接著分成上下兩條路，這是這一頁的重點。上面那條是營運路徑，解決當下：產生會議紀錄、提取決議與待辦、把任務丟進專案管理系統。注意最後一格——它不會覆蓋人類手寫的紀錄。下面那條是知識路徑，投資未來：去掉贅字、把客戶名稱這類敏感資訊蓋掉，做分類與摘要，最後整理成可以查詢的概念頁。一場會議，兩條路徑。上面那條讓顧問願意錄，下面那條才是公司真正賺到的。這個設計很重要：如果只有下面那條，錄音對顧問來說就是純粹的額外負擔，推不動。

我們把其中一句話拆開來看。第一步，原始輸入。會議上顧問這樣講：客戶那邊生產部的王大明說他們不想用新系統，因為績效指標沒改，做這個只會讓他們這個月達標率變難看，我們是不是要先找主管談？這句話很口語，也帶著客戶的真名。第二步，清洗與分類。系統去掉贅字，把王大明改成「生產部窗口」，然後抓出兩個核心議題：系統導入的阻力，還有績效指標的衝突。第三步，概念化與連結，變成一個可以重複使用的知識節點。請注意第二步做了兩件事：一件是保護客戶，另一件是把個案抽象成通則。少了後面這件，留下來的只是一堆會議紀錄。畫面右下角那句話，是這一集的中心思想：您要累積的不是一個範本庫，是四十個案子裡真正學到的那幾十條實戰法則。

那些法則平常怎麼用？畫面上方是提問：製造業推流程改造，生產部門抵抗怎麼處理？底下的回答分成兩塊。第一塊是洞察：如果抵抗的來源，是既有的績效指標在新流程底下對那個部門不利，那直接討論流程通常沒有用，應該先跟部門主管談指標的調整。第二塊是驗證：這個判斷已經在多個製造業專案中驗證過。這一句「已經驗證過」很重要——它把一個人的直覺，變成公司的判斷。最底下那一行是溯源：出處，某某專案週會錄音，原始逐字稿第二十七分鐘。您可以直接回去聽當時是在什麼情況下講這句話的。有出處，才敢拿去跟客戶講。

要讓顧問願意用，有三件事一定要先講清楚。畫面上三根柱子。第一根，互補不覆蓋。系統產出的會議紀錄只會填補空白的欄位，絕對不會覆蓋或修改顧問自己手寫的內容。顧問最怕的就是「我寫的東西被改掉了」，這一條是為了這件事設計的。第二根，專家把關。系統整理出來的知識只是提案，必須經過專案經理或知識管理負責人核可，才會正式進到知識庫。機器不能自己決定什麼叫公司的方法論。第三根，嚴格的資料界線。方法論與通則放在公開範圍，客戶的專案資料綁定團隊標籤。沒有權限的人查詢，系統顯示的是「查無資料」，不是「您沒有權限」——這一點對顧問業特別重要，因為連「我們有這個客戶」都屬於保密的範圍。

前面講的都是內部效率，但這一頁講的是收入。畫面上半，沒有知識庫的時候，提案桌上講出來的是：我們在這個領域有豐富的經驗。右邊那個標籤很誠實：依賴記憶，缺乏細節。這是一句形容詞，客戶聽過太多次了。畫面下半，有知識庫之後講出來的是：我們做過五個類似案子，其中三個遇到績效指標的阻力，我們的處理方式是先調整主管的績效指標。右邊的標籤是：瞬間調用，無法反駁的實績。同一家公司、同樣的過去，差別只在於坐在客戶對面的那三十秒，講不講得出來。而且下半那句話，年資兩年的顧問也講得出來——因為它不靠記憶，靠的是公司的庫。畫面最底下那句話是給合夥人看的：最直接的價值不是省了多少時間，而是提案成交率的提升。

導入之後可以合理期待什麼？畫面上三項。啟動加速：專案準備的時間縮短三成到五成。去重複化：重複製作相似交付物的情況明顯減少。流失防禦：顧問離職造成的專案知識損失大幅下降。中間那行小字要念清楚：這是導入目標與合理預期，實際成效取決於會議有沒有錄、核可有沒有做。底下那個式子才是給經營者的：顧問公司的估值，等於累積的方法論，乘上能執行的人。多數顧問公司的方法論只存在資深人員的簡報檔裡。人走了，那一項就跟著歸零。把日常對話轉成結構化的資產，是鞏固估值的唯一路徑。

最後這一頁，是一個值得帶回公司的問題：明年這個時候，您們會再結案三十件。那三十件，會留下什麼？如果要開始，畫面上三步。第一步，盤點現況，看看現有的專案會議與結案報告，目前保存到什麼程度。第二步，尋找痛點，找出最常重複投入資源的那一條業務線。第三步，試點規劃，一起評估導入範圍，小規模先試做一個。建議從一條業務線開始，不要一次全公司上——顧問業的接受度是靠幾個人先用出心得帶起來的，不是靠公告。聯絡方式就在畫面上。這裡是智庫引擎，我們下一集見。