為什麼你提的建議，不會被採納？
——一次事故的覆盤拆解，以及我用來判斷「該做什麼、什麼不必再試」的可行度判斷四道關卡
三行摘要
- 一次作業事故讓我發現，原來問題不單只是資料沒有同步，而是沒有任何環節有義務能自動地發出訊號。
- 我原本以為漏了通知就是自動化可以解決的問題。拆解之後的結論是：能做的只有一半，另一半不該做。
- 這篇記錄我用來自己判斷「當遇到跨部門協作 + 需要團隊持續接力的責任義務歸屬時，哪些卡點該解、哪些不該碰」的框架，以及一份路過觀眾可直接參考使用的決策紀錄格式。
開場：我是靠運氣才知道的
你有沒有遇過這種事——某件事已經出錯了，而你不是「比較晚知道」，你是事前不知道，只是剛好有人發現了。
執行日的前一天，一位由外部指派的監核人員依照程序拆封清點——那是他的職責，也是這批物資唯一一次被核對的機會。數量和實際人數對不上，少了幾份。
我與外部單位聯繫上。
「我們是照你提供的數字準備的。怎麼會短缺呢？」
帳面上，負責人掛的是我。
「這中間發生了甚麼事，請待我查清楚再回覆你。」
追下去才知道，鏈是這樣斷的：
執行日前一天傍晚，前端更新數字；與這數字接手的第一執行者依照新的人數，從庫存多領了幾份可以囤放的物資——那其實是一個訊號，但領用的人不知道它同時代表著什麼；而我因為特定時間點已過，加上前期物資數量充足，沒有必要再回頭查核。平時會提醒我的同事，那天請假。
從頭到尾，大家都做了他該做的事。而這一次能被攔下來，靠的是那位監核人員剛好提早拆封確認。
這是運氣。它也暴露出一個不常發生、但只要出現特定變數就可能相當致命的風險。
那個週末，三件事同時成立：加單的權限持續開放、全公司沒有人在線、而且沒有任何一個時點宣告過人數已經定案。從週五中午到週一早上，六十九個小時。
在這段時間裡，任何人都不可能提前知道數字變了——這段時間本來就沒有任何人看守。
當一件事必須靠「某人剛好記得」才能運作，它就不是流程問題，是運氣問題。
我把這件事拆完。以下是拆解的過程，以及我最後決定不做的那些事。
一、第一直覺是錯的
我最初以為這是一個自動化可解的問題。
因為我每週固定要做一件很像機器人的事：
- 打開內部共用排程表，用眼睛掃一遍當月狀態表，看看哪個案件的人數更新了；
- 有變動，就到另一份與外部單位共用的線上表格，手動更新數字。
無聊、重複、沒有技術含量。
看到這個場景，大多數技術宅的直覺會是：「這可以做為自動化案例吧！？」
是的，我也是這樣想的。
因為這次的事故，我重新拆解一遍之後，我發現自己解錯題了。
這裡其實有兩個獨立的問題：
- 搬運問題——數字從內部 A 表抄到外部 B 表。無聊、稍微耗時，因為簡單，沒有造成過任何損失。內外部表單沒有程式可以串接著力的地方（A與B之間沒有結構化資料與方式可以傳遞），也所幸內容變更與頻率不算高，殺雞焉需用牛刀，故沒有投入資源更改的必要性。
- 事件問題——有人在A表改了數字，而原本下游該接棒的人沒有收到訊號。造成損失與應該接棒的人持續接收原本可避免的壓力，一直是這件事。
它們是長得很像，因為都圍繞著同一份資料。
但性質完全不同：搬運耗費的成本單純只是我的時間，但事件發生的成本是看似營收進帳，實質卻暴露營運的風險。
回覆外部單位那天，我把自己能做與不能做的部分拆成三段：
- A｜我每週主動查看內部表單一到兩次，並更新共用資訊。
- B｜除此之外，若有同事提醒，我會在當天更新。
- C｜但我無法控制的是——只要有人異動了資訊而我不知情，A 和 B 都跟不上。
C 才是問題的全部。 A 和 B 都是我單方面就能做的努力，而它們的效果上限，取決於一件我完全無法控制的事：有沒有人剛好告訴我。
事後我把可能通知到我的路徑全部列出來，發現有三條，而那一次三條同時失效：內部表本身沒有通知功能；行政依新人數多領物資的動作其實是一個訊號，但領用的人不知道它代表什麼；而唯一會主動提醒我的同事，那天請假。
三條都不是被設計出來的路徑，所以三條都可能失效——這一次剛好同時發生。
純粹的搬運工很無趣，所以我原本想解的是搬運，但真正會出事的關鍵不是資料搬運工。
二、為什麼斷點會致命
事故發生後，有個問題是，既然發現得晚，為什麼不多備一些庫存就好？
這些過程與問題讓我覆盤許久，我把這段經歷寫下來，思考解構出我認為有價值的地方。
我需要準備的資源分成兩類。
可緩衝資源：可以先備好放著，要用時馬上拿得到。發現得晚，問題不大——因為庫存把等待的時間吸收掉了。
不可緩衝資源：不能先準備放著，每一次都要重新等固定的時間。而且往往正因為管控、合規、機密，或者是時間等....原因，預先囤放這件事本身是風險。它不能單純靠庫存解決，反倒是因為庫存正是它要避免的。
而這次事故裡的那項資源，還有第三個性質，這是我事後才想清楚的：它不能事先拆封查驗。封裝本身就是管控的一部分，只有在執行當下、由特定授權角色拆封時，數量才第一次被核對。
換句話說：
這類資源的錯誤，必然在最後一刻才浮現。不是因為誰不夠細心，而是驗證點在物理上就被設計在最後。
這一點很重要，因為它擋掉了最容易被丟過來的那句責難——「你怎麼不早點檢查？」早點檢查在這裡不成立。
而既然驗證點不能往前移，剩下的結論就只有一條：
當驗證點無法前移時，唯一能前移的是資訊。
這個區分不是我服務這個產業獨有的。幾乎每個行業都有自己的版本：
| 產業 | 可緩衝資源 | 不可緩衝資源 | 一旦太晚知道 |
|---|---|---|---|
| 餐飲 | 乾貨、餐具、包材 | 當日生鮮、預約桌次 | 食材不足，當天出不了餐 |
| 製造 | 標準件、耗材 | 客製模具、外部檢測報告 | 產線停線等料 |
| 醫療 | 一般耗材 | 需預約的檢查時段、特定藥品 | 病人白跑一趟或延誤 |
| 活動 | 文具、飲水 | 場地檔期、外部講者時間 | 活動開天窗 |
| 營建 | 常備五金 | 監造簽核、外部檢驗 | 無法報驗、工期延宕 |
一個通則：
流程的容錯能力，由其中最不可緩衝的那項資源決定。
這是專案管理中的 Critical Path 或是 Bottleneck。
緩衝其他所有東西都沒有用。只要鏈條上存在一項不可緩衝的資源，整條鏈的韌性就等於那一項的韌性。
回到最初那個問題：那就多備一些庫存吧？
這個解法對可緩衝資源成立，對不可緩衝資源恰好相反。它之所以不能囤放，是因為囤放本身就是它要防的風險——封裝管控存在的理由，就是讓這批東西在被正式啟用之前，沒有任何不相關的人能接觸到內容。
用囤放去解決短缺，等於拆掉封裝管控存在的理由。
這件事的關鍵是自身立場。一個以管控為專業的組織，如果對自己的管控資源採用「先囤著比較保險」的邏輯，那條防線在對外說明時就站不住。而且一旦真的外流，你連何時、何地外流的都無從查起。
由此再推一步。
當流程中存在不可緩衝資源時，「偵測延遲」就等於「風險暴露時間」。
是這個結論，讓我對這件事又再重新思考一次。我原本以為我在解決一個資料同步問題，實際上我在解決一個時間問題——從「有人改動」到「我知道」之間的那段空白，這才是真正的風險所在。
而這段空白之所以存在，和收單政策直接相關：
高彈性的收單政策換來成交速度，代價是後段流程的不確定性大增。
這是一個真實的取捨。彈性收單確實帶來業績，這一點沒有異議。
問題只在於——取捨的兩端，由不同的人承擔。
而前端做完了一部份，後面承擔的人還要多負擔突發意外的工作。
三、為什麼斷點不會自己修好？
我一開始以為，只要把問題講清楚，或是用自動化的技術解，它就能夠被修正。
後來我發現問題不在這。而這原因出在誘因的分佈方式。
把一次「臨時追加需求」拆開來看：
- 收益——立即發生、數字明確、歸屬清楚，而且進入決策端的損益表。
- 成本——延後發生、數字模糊、由下游多人分攤，不進入任何人的損益表。
後段流程多花的時間、承擔的風險、來不及時的補救、耗費的心力持續堆積，在組織的帳本上不存在。
這項成本它確實存在，只是不會"被認定存在"，就不會構成調整的理由。
當收益歸屬與成本歸屬分屬不同角色時，承擔方會持續吸收無法計價的成本，而決策方缺乏調整誘因。（或說是權力結構的不對等）
再回頭看開場那條鏈，會發現一件更精確的事：訊息其實傳遞了。行政依照新人數多領物資的那個動作，本身就是一個訊號。
訊號不是不存在，是它出現在一個不知道那是訊號的人面前。
而唯一有機會把訊號翻譯出來的那條路徑，是「平時會提醒我的同事」。就這麼剛好，那天請假。
(我的責任範圍沒有義務天天主動查詢)
一條依賴特定某個人的訊息鏈，它的可靠度上限就是那個人的出勤率。
請假是必然會發生的事。一條會被請假打斷的鏈，本來就不該被當成鏈。
這也解釋了另一件事：為什麼「已有規範」，卻仍然反覆發生？
規範確實存在，而且被明確布達過。但一條規範要能真正運作，至少需要三件事。
- 觸發點——什麼事件發生時，這條規範（要做甚麼事情）就要啟動？
- 檢核節點——由誰、在哪一步，確認它被執行了？它有紀錄嗎？
- 失效後果——沒做的話，誰會知道？會怎樣？
只要缺少這些要素，規範就會變成容易被忘記的提醒。而這在忙碌時太容易被跳過了——這是資源排序下的必然結果。
一條沒有觸發點、沒有檢核節點、沒有失效後果的規範，在系統上幾乎不存在。
有一個很容易被誤解之處。當同一件事反覆發生，直覺會歸因為「執行的人不夠自律、老是忘記」，於是解法就變成再宣達一次、再提醒一次。
但真正的問題還是一樣，不該由是否自律，是否真的牢牢記得，才能變成解法。
如果是接力賽，就該要確保下一棒一定會收到通知而非靠記性。
如果上述的三個條件都不具備，換誰來執行，結果都會一樣。問題出在規範本身的設計。
而要修復它，需要有權者主動限縮前端的彈性——用確定的業績損失，去換不確定的風險降低。
任何組織放在這個誘因結構下，不大可能優先採用上述的做法，最終都會導向輸出相同結果。
清楚這一點之後，我停止在這個方向上投入。
延伸閱讀｜關於這一點，我另外寫了一篇。
規範明明寫清楚了、也確實布達過，為什麼還是不會被執行？我原本想把它寫在這裡，但拆下去之後發現它自成一個題目，硬塞進來只會模糊這篇的焦點。
那篇談的是：一個行為要穩定發生需要什麼、為什麼 SOP 一項都給不了，以及「換載體」有哪些具體的分級與做法。
🔗 〈規範寫了卻沒人做：不是靠紀律與記得〉
四、理想長什麼樣子？
寫到這裡，我猜想你可能已經在心裡列出解決方案了。我想到的是：
理想解一：一套共用的系統，而不是一份人人可改的檔案。 （知道甚麼時間點、變動了甚麼，這就是資料治理啊~ 心中吶喊一萬萬次）
關鍵欄位設定權限分級，前端只能新增、不能覆寫；每一次變更自動留痕，記錄誰、在什麼時間、把什麼改成什麼。
理想解二：自動的下游通知。 （接下來應該要做甚麼、怎麼確保大家都知道）
任何影響下游備料的欄位一旦變動，相關角色立刻收到訊息。這不需要任何人記得交給下一棒的細節，系統自己會說話。且必定要確保相關角色務必收到消息，且有互相提醒的機制。
理想解三：把後段成本計入前端的績效。 （臨時追加的額外成本，可以共同分攤）
只要「臨時追加」的處理成本會出現在某一份報表、某一份心理帳單上，就不用任何規範，行為自己會調整。
我希望解除這些痛點。
但這三個理想解有一個共同點：它們全都需要別人先改變。
解一：需要決策者同意限縮前端的操作彈性。
解二：需要更換工具或投入預算。
解三：需要重新設計績效制度
以上這每件事情都是組織中阻力非常高的事，特別是第三項。
在沒有預算權限，沒有部屬協助，也沒有調整他人考核指標的位置。提案面臨了政治問題，被採納的可能性.....
當一件事牽涉到利益分配，而且成本根本不在對方的思考範圍裡，再多道理都不會有效果——因為我們心中評估的不是同一份帳本。
你知道我知道，獨眼龍也知道。
承認這一點，也不是直接放棄。我的判斷是，先計算哪些做得到，在理想與現實中選擇能做到的部分。
先問自己，眼下我自己能掌控的部分，到底有什麼？
專注在自己能改變的地方，然後真的把它做出來。
這是成熟工作者與抱怨者之間的分界線。
想再多都是問題，開始行動後，答案在我前進的路上。
五、換一把量尺：可行度判斷的四道關卡
如果制度層動不了，那我到底還能做什麼？
我發現我原本評估方案的選項可能還不夠多。
（零偏見決斷法帶給我最受益的思考法，當你卡住時別在現有的選項打轉，想辦法多增加選項）
評估現行方案，有幾個維度：
管理（老闆同意嗎）、技術（做得出來嗎）、利益成本（誰受益受損？）、成本（負擔得起嗎？）、時間（來得及嗎？）
這幾個項目，目前都不可行。
還有一條路，政治可行度——這個方案需要「誰」改變行為？那個人有動機改變嗎？
當我用「誰必須改變」重新分類卡點時，似乎突然變得清楚 （但仍然不是理想）。
我把它叫做可行度判斷的四道關卡——它衡量的是誰必須改變。
- 第 1 層 | 只有我——我一個人就能做完，成本是我的時間。
- 第 2 層 | 我談得動的人——對方沒有反對誘因，講一次就成，成本是一次溝通。
- 第 3 層 | 我談不動的人——需要有權者改變誘因結構。成本極高；與其利益衝突時，趨近無限。
- 第 4 層 | 沒有人能改——工具或物理層面本來就沒有這個能力。
這張圖最有價值的地方，是它揭露了一件我原本沒看見的事：
第 3 層和第 4 層，對執行者而言是同一件事——都是「無論你多努力都不會動」。
差別在於物理面與人為面，政治與技術經驗的判斷讓我理解到不可行。
我在第 4 層從來不會挫折。工具做不到就是做不到，我不會生氣。
但我在一開始第 3 層耗掉了大量的力氣與情緒勞動，因為它最初看起來是有機會變好的。
把兩者放進同一片斜線區之後，那些力氣就省下來了，放過自己吧。
我得出一個新的決策規則：
在受限環境中，最優解不是效果最好的方案，而是「第 1 層範圍內效果最好的方案」。
這不是妥協。把第 3 ~4 層的方案納入比較，心累又沒效事情還不能推進，徒耗時間。
漸漸地我體悟到，面對卡點與痛點，有沒有一個只需要我自己改變的省力版本？
這或許才是最小可行性方案。
六、我實際做了什麼，沒做什麼
結論如下。（以下內容純屬虛構，如有雷同，那就雷同。）
判定為第 3 層，不執行
- 明確建立收單截止點。 技術上零成本，只需要規則與實際上無管道使其發生就搞定。 但它要求決策者用確定的業績去換不確定的風險降低，誘因反向。曾經嘗試過，以前在別處有效（因為這項成本在別處有感），這裡完全無效（此處原因如前所述），不需嘗試。
- 讓內部共表的執行方式作調整。 這會讓程序能夠判讀狀態，是後續自動化的前提。但那份表所有人都在看、都在填，要改變全體的使用習慣，成本可能遠高於收益列為待用選項，不主推。
判定為第 4 層，繞道
- 試算表檔案沒有儲存格層級的事件機制。 這是工具先天的限制決定的：雲端原生的表格工具，底層事件模型是「儲存格」；而被搬上雲端的試算表案，底層模型是「檔案」——系統只知道檔案被存檔了，不知道裡面哪一格變了。 繞道：放棄事件觸發，改用定時快照比對。
- 內外表單是多人同時共同編輯，不支援外部程式寫入。 所以一開始就不從這個方向切入。
判定為第 1 層，執行
這是我唯一能單獨決定的範圍。先說清楚：這部分還在進行中，以下寫的是原則，不是已完成的成果。
我定了三條：
- 把「等人通知」換成「我自己定期去看」。 不再依賴上游記得，固定時間主動檢查。本來就在做。
- 工具設定半自動化提醒，只在真的有變化時才出聲。 如果每天都收到「今天沒事」，一段時間後會疲乏就很容易忽略再打開它了。(可行性測試中)
- 機器負責提醒，人負責判斷。 我不追求全自動。只要能讓我早一點知道「有東西變了」，剩下的判斷仍然由我來做。
這三條的共同點是：它們都只需要我自己改變。 效果一定比不上前面那三個理想解，但它們很快就能開始。
成功指標跟著改
我原本會把目標寫成「不再發生短缺」。
現在不會了——因為那需要收單截止點，而截止點是第 3 層。
承諾一個依賴他人改變的指標，等於把自己的成敗交給別人。
新的指標：縮短「有人改動」到「我知道」之間的延遲。 目標是把它從數天壓到一天以內。
這個指標完全落在第 1 層。它不需要任何人配合，不需要任何預算，也不需要任何人改變習慣——所以它的成敗完全在我自己手上。
收尾：它修不好斷裂，但它讓斷裂留下痕跡
這套做法有極限。
它不會讓臨時追加的需求消失。不一定能讓前端多想一步。不會讓那條規範突然長出檢核節點。所有的結構性問題都還在原地。要是它在假日發生，我也還是沒輒。
也必須誠實說明進度：到我寫下這篇為止，那套定期檢查的機制還沒有做出來，可行性尚未驗證。我確認過工具大致能走到哪裡，但「在目前這個環境裡到底跑不跑得起來」，還沒有答案。
所以這篇是一份判斷紀錄。
自動化不能修復斷掉的訊息傳遞，它只能讓斷裂留下時間戳。
這件事的價值，在這裡。
在此之前，這件事的狀態是「我沒有被告知」。這是一句口說無憑的抱怨，除了讓自己不舒服之外，不產生任何作用。
如果這件事做成了，它的狀態會變成「紀錄顯示，某月某日某時，某項數字發生了變動，而當下沒有任何人被告知」。
那會是一份帶時間戳的事實。它不需要任何人同意就能存在，也不需要任何人改變行為就能累積。
而當有一天，成本大到終於進入決策端的帳本時——那份紀錄就是唯一能說話的東西。
在那之前，我能做的不是說服，是把事情記清楚。
開場那件事之所以沒有釀成事故，是因為有人剛好提早拆了封。
我沒有辦法保證下一次也有人剛好。
我能做的，是把「剛好」的比重往下壓。壓不到零，但每壓低一分，就少一分依賴運氣。
判斷「不做什麼」，和判斷「做什麼」是同一項工作。
附：決策紀錄格式
我把整個拆解過程整理成一份可重複使用的格式。它記錄的是我評估過什麼、決定不做、以及為什麼。
用法很簡單：先填「誰必須改變」，再判層級。 那一欄決定了其他所有欄位——第 3、4 層一律不投入，第 1 層先做。
索引表
| # | 卡點 | 誰必須改變 | 層級 | 判定 | 重估觸發 |
|---|---|---|---|---|---|
| 01 | 狀態靠視覺樣式呈現：人一眼就懂，程式完全讀不到 | 全體使用者 + 決策者 | 3 | 暫不執行 | 換系統時一併處理 |
| 02 | 共用檔案只知道「被存檔了」，不知道「哪一格被改」 | 無人 | 4 | 繞道：改用定期比對 | 工具釋出新能力 |
| 03 | 多人同時編輯，程式若也寫入會蓋掉別人的內容 | 無人 | 4 | 繞道：程式只讀不寫 | — |
| 04 | 流程沒有收單截止點 | 決策者 | 3 | 不執行 | 外部稽核出現缺失 |
| 05 | 規範存在，但沒有觸發點與檢核節點 | 決策者 | 3 | 繞道：以偵測取代通知 | 同 04 |
| 06 | 我定期主動查看，是唯一穩定的資訊來源 | 只有我 | 1 | 已在執行 | — |
| 07 | 口頭提醒是唯一的補充管道，該同事不在時沒有替代 | 只有我 | 1 | 未解決 | — |
我自己的狀況怎麼寫的?
索引表是拿來掃描的，真正的判斷寫在詳細卡裡。前六欄與索引表相同，另外再加四欄。
01 狀態靠視覺樣式呈現：人一眼就懂，程式完全讀不到
誰必須改變 全體使用者 + 決策者
層級 3
判定 暫不執行
重估觸發 換系統時一併處理
判定理由 用顏色或字體標示狀態，對人來說是最快的辨認方式，
所以大家自然這樣做。但那些樣式對程式而言不存在——
程式讀到的只有欄位裡的值。
為了讓人看得快而做的設計，正好是讓機器看不見的原因。
同一份資料要同時服務兩種讀者，
而現在的呈現方式只服務了其中一種。
失效成本 所有需要判讀狀態的自動化，起點就被堵住。
繞道方案 狀態判讀保留人工，自動化只處理數值欄位。
證據來源 親身經歷 + 工具官方文件
記錄日期 2026-08
07 口頭提醒是唯一的補充管道，該同事不在時沒有替代
誰必須改變 只有我
層級 1
判定 未解決
重估觸發 —
判定理由 請假是必然會發生的事。
一條會被請假打斷的鏈，本來就不該被當成鏈。
失效成本 下游是否知情，取決於某人是否剛好在崗位上。
最壞情況：不可緩衝資源在執行當天才發現不足。
繞道方案 候選一｜指定職務代理人 → 不採用。
代理人仍然是「靠人記得」，只是換一個人記，
結構沒有改變，失效模式完全相同。
候選二｜排程檢查工具 → 待驗證。
可行性與資源皆尚未確認。
證據來源 親身經歷 × 1 次
記錄日期 2026-08
第一條的價值在於它指出一個常被忽略的落差；第二條的價值則在那句被否決的理由：
換一個人來記得，不等於不靠人記得。
07 停在「未解決」。一份所有問題都被關閉的紀錄，通常是事後美化XD
空白版，歡迎直接取用
| # | 卡點 | 誰必須改變 | 層級(你能不能動) | 判定(怎麼做) | 重估觸發 |
|---|
三行使用說明：
- 先填「誰必須改變」，層級自然就決定了。
- 第 3、4 層一律不投入，但要寫下理由——那是為了下次不用重新想一遍。
- 每一條都要有「重估觸發」。沒有這一欄，這份文件只能記錄但沒法有改善機會了。
如果你也在一個「看得見問題、但動不了源頭」的位置上，我認為它至少能幫你分辨：哪些挫折是你該繼續投入的，哪些其實你早就已經完成判斷。
我花了不少時間反覆與AI對話，釐清我自己感受痛苦的地方在哪裡，我在意的地方是甚麼，一個組織的流程與作業模式，問題會在哪裡？
想起劉潤書中的一段話，大意是：
結果 = 正確的執行方式 x 機率，而非倚賴運氣。
因為實在很痛，所以我願意投入這麼多時間記錄下來替自己覆盤，希望也能幫助到你。
