概念地圖・試點煉獄
作者 山姆（謝冠生）・喵喵書評創辦人
發布
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
試點煉獄：二十四個試點，只有兩個走出試辦
一份土壤整治的期末報告，封面蓋著「試辦完成」四個字，內頁最後一行建議全廠導入——那份報告放了十四個月，沒有人被指派要做那件事。試點煉獄講的就是這一段路：技術驗過了、報告收了、然後懸在那裡。這不算失敗——失敗至少會被記錄、會被檢討、會有人做決定。它只是沒有下一步。把一年裡啟動過的試點排成一張漏斗，三層之間的落差會自己說話，而每一層真正的死因，幾乎都不寫在技術那一欄。
漏斗三層，各自漏掉什麼
先把三層拆開來看：每一層在做什麼、走到那裡還剩幾個、死在那一層的人長什麼樣子。
| 這一層 | 「通過」的意思 | 示意數量 | 死在這一層的招牌症狀 |
|---|---|---|---|
| 啟動試辦 | 有預算、有人做、真的開跑 | 24 個 | 報告寫完就結案，推廣負責人那一欄從頭到尾是空的 |
| 進到正式評估 | 有人真的看數據，決定推不推 | 9 個（37.5%） | 要另外登入一個系統、同一筆資料要重打一次，現場先放棄 |
| 推到全公司 | 寫進流程，變成日常做法 | 2 個（22.2%） | 成功的定義停在「做完」，沒有人問過使用率長什麼樣 |
三層的落差不是平均分布的——最大的一刀落在第一層，二十四個裡有十五個根本沒走到「有人看數據」那一步。這一刀落下的位置其實很固定：報告交出去之後，公司裡沒有任何一個具體的人，年度目標會因為這個試點多一條。於是它既沒有被否決，也沒有被推動，就這樣掛在「今年有在做創新」那一格上，一年之後還在原地。整體算下來，二十四個裡真正推到全公司的只有兩個——8.3%。要注意的是，這張圖底層的寬度並沒有照 8.3% 去畫；真按比例縮，那一條會細到放不下任何一個字，所以比例交給旁邊的數字說。
一個試點該不該啟動，看四個入場條件
入場條件的用處在於「當場就能檢查」——四條都要在按下啟動之前答得出來。事後補的答案救不回已經跑掉半年的試辦。
一、推廣負責人那一欄，現在寫得出名字嗎。這一欄要填的是一個人的名字，填部門等於沒填。試點做完之後要有人把它往外推，而「往外推」是一份要開會、要吵架、要改別人動作的工作。這件事沒有被寫進誰的年度目標，它就不存在。自問：這個試點成功之後，是誰的年度目標會因此多出一條？
二、它要接進哪一套既有系統，那邊的窗口點頭了沒。試辦階段只有三五個人，多開一個網頁、多打一次資料，大家會忍。放大到全公司，同樣的動作乘上幾百人再乘上一整年，就變成一筆沒有人肯簽的成本。啟動前先去問那個系統的窗口——他說「要排」，那就是排到明年。自問：全面導入之後，第一線要不要多開一個帳號、多打一次同樣的資料？
三、成功的定義寫的是使用率，還是報告交付。「完成三場試辦、產出一份評估報告」是一個交付定義，它保證你會準時做完，也保證做完之後沒有下文。改成「六個月後有多少比例的案場用新流程回報」或「哪一張舊表單可以停用」，整件事的設計會從第一天就不一樣。自問：三個月後我要拿哪一個數字出來，才算「這件事成了」？
四、全面導入要花的錢與人，在啟動之前有人估過嗎。試辦的預算通常是零頭，導入的預算是另一個量級——設備、授權、教育訓練、過渡期的雙軌作業。這個數字如果到評估會議才第一次出現，會議只會有一個結果：再研究看看。自問：如果現在就要簽全面導入的預算，那個數字是幾位數，誰簽？
一家土壤整治工程公司，二十四個試點走一遍
- 一年開了二十四個試辦：新的採樣動線、現地處理的加藥配方、監測井的無線回傳、報價估算表、工班日報數位化。題目都不是亂挑的，每一個都來自某次現場的抱怨。技術部門的驗證能力從來不是問題
- 十五個停在期末報告：封面蓋「試辦完成」，最後一行寫「建議全廠導入」。報告發出去之後，沒有人收到任何一封指派信。沒有人被指派，也就沒有人會被問進度
- 九個進到正式評估：這九個的共同點很土——當初提案的人自己就是每天被那件事煩的人，所以他一路追著要開會。痛得夠具體的題目，會自己找到推的人
- 七個死在系統的接縫上：監測井的無線回傳做得很漂亮，但數據落在廠商的網頁上，工班的日報還是得手抄一次再打進公司的工單系統。放大到三十個案場，等於每天多幾十次重打。多一次登入，就是多一個不做的理由
- 兩個推到全公司：一個是採樣動線，一個是報價估算表。兩個都在啟動當天就寫了推廣負責人的名字，也都在第一週就跟工單系統的窗口確認過接口。入場條件在啟動那天就把後面的路鋪好了
把這二十四個攤在一起看，通過率其實還算次要，真正刺眼的是死因的一致性——十五個死在同一件事上：報告寫完的那一天，沒有人的工作因此改變。技術驗證這一段公司做得很好，好到讓人以為問題出在題目挑得不夠準；實際上活下來的兩個，題目挑得也沒有比較高明，差別只在啟動當天多做了兩件事：寫下一個名字、打一通電話給系統窗口。這兩件事各花不到一小時，卻決定了後面半年的成敗。反過來說，如果那四個入場條件當初就掛在啟動表單上，這家公司一年可以少開十五個註定要停在抽屜裡的試辦，把同樣的人力壓在剩下的九個上面。以上為說明結構用的示意情境，僅供理解框架之用。
這個試點漏斗什麼時候會騙你
漏斗好用，但它有三個內建的偏誤，而且都是往「讓你安心」的方向偏。
- 形狀本身在幫你合理化死亡。上寬下窄是漏斗的定義，於是「這一層漏掉一半」看起來像自然律，而不像一件該檢討的事。真實情況是：十五個停在第一層，其中大部分死於同一個可修的原因，只要啟動前多問一句就能避開。把它畫成漏斗，這十五個就從「十五次組織失能」被翻譯成「篩選過程」。看這張圖的時候要刻意抵抗這個翻譯——每一層漏掉的數字都該有一份死因清單，不是一個百分比就結案。
- 它只數啟動過的試點。圖上這二十四個，是有人提案、有人批准、有預算的那些。那些連提案都沒送出去的呢？第一線覺得「講了也沒用」而吞回去的呢？那些常常才是真正需要被試的題目。漏斗天生看不到未被批准的區域，所以它永遠不會告訴你「你們公司過濾掉的是哪一類題目」。要補這個洞，只能靠另一份東西：一年裡被打回票或根本沒送出的構想清單，以及打回票的理由。
- 把通過率當 KPI，最快的作弊法是少啟動。今年 8.3%，明年想拉到 20%，最省力的做法很難看：把啟動數從二十四砍到十。分子不變、分母縮小，報表立刻漂亮。這個誘因非常強，強到很多公司會不自覺地照做——表現出來就是「我們今年只做重點試點」。真正該追的是絕對數字：今年有幾個試點變成了全公司的日常做法，以及它們合起來省下多少人時。
試辦完成之後，本來就不歸技術管
試點的成功定義寫的是「做完」，而做完不會讓任何人的痛變輕一點。
《痛點》那把尺問的第一件事是誰在痛。放到試點上，這個問題會變得很尖銳：這個試辦如果成功，是誰每天少做一件事、少被誰催一次？答不出來，它從一開始就沒有接手的人——因為根本沒有人在等它。二十四個裡活下來的那兩個，共同點很土：有人早就被那件事煩很久了，試辦只是把他的煩換成一個可以簽的方案，所以他會自己去追進度、去吵預算、去堵系統窗口。這張漏斗畫得出每一層還剩幾個，畫不出被留在上一層的那些試點裡，誰的痛本來要靠它變輕——而那個「誰」，正是決定它會不會被接手的唯一變數。今晚可以做的很小：找出上一個做完就沒下文的試點，看它的負責人欄是空的還是有名字。
關於試點煉獄，常被問到的幾件事
試點煉獄跟一般的專案失敗差在哪？
失敗有結論。不管是收掉還是改方向，都有人做過一個決定，也留下了可以檢討的紀錄。煉獄沒有結論：報告寫著「試辦完成、建議導入」，然後停在那裡，沒有人反對，也沒有人推。它在帳面上還活著，還佔著一格「今年有在做創新」的成績，實際上沒有任何人的工作因為它改變過。判斷方法很簡單：問這個試點現在的負責人是誰，如果答案是某個部門，那多半代表沒有人。
一年該啟動幾個試點才合理？
數量沒有標準答案，但有一個好用的反算：先問公司一年真正吃得下幾次全面導入。導入要教育訓練、要改表單、要動既有系統、要撐過雙軌並行的過渡期，一家中型公司一年能好好吃下的大概是兩到三次。倒推回去，能認真評估的十來個，能啟動的二、三十個——這也是這張圖用 24 當刻度的理由。啟動數如果遠遠超過這個量，多出來的那些從第一天就注定停在報告階段，因為沒有人有餘力接。
試點都通過了，為什麼還是推不動？
通過通常只證明了一件事：技術上做得出來。全面導入還要另外三樣——第一線願意改動作、既有系統肯開一個接口、有人願意把它寫進自己的年度目標。這三樣都不歸做試點的人管。最常見的卡點是系統：試辦時大家可以忍受多開一個網頁、多打一次資料，因為只有三個人、只有兩個月；放大到全公司，同樣的動作乘上幾百人再乘上一整年，就變成一筆沒有人肯簽的成本。
營運負責人一定要在啟動前就指定嗎，做完再找不行嗎？
做完再找，成功率會低很多。試辦跑完的那一刻，數據、坑、例外狀況全在做試點的人腦子裡；這時才空降一個營運負責人，他得從零開始理解一件已經結案的事，而他今年的目標裡沒有這一條。啟動前就把名字寫上去，那個人會在過程中一直問「全廠要怎麼跑」，這些問題會直接改變試點的設計——這才是指定負責人真正的價值，跟找一個人扛責任是兩件事。
試點過不了的另一種死法是錢斷在中間——技術和組織都到位了，兩筆預算之間卻接不上，那條溝在創業死亡之谷另外畫過一次。至於這張漏斗的上游，創新漏斗篩的是還沒被驗證的構想，卡在「想清楚」之前；篩完剩下的才會變成這裡的二十四個試點，卡在驗證之後、導入之前。兩張圖接在同一個點上：構想被批准去試的那一天。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。