外包邊界、規模化與危機處理

外包邊界、規模化與危機處理

這是「營運、團隊與管理」的最後一課，也是把前面四課收攏成一個判斷的一課。流程當責與品質讓每個步驟有一個叫得出名字的負責人與一份寫下來的品質標準；指標與營運節奏讓這些步驟的狀態每週被看見；招募與職務設計決定用什麼樣的人填進這些角色；績效、誘因與文化決定這些人被什麼推動。這一課問的是三個更外層、也更難回的問題：這個步驟到底該不該由我們自己做？當需求變成兩倍半時，這套系統會從哪裡先斷？以及當它真的斷掉的那一天，公司要怎麼運作？

全課沿用整個課程群的教學公司「順風物流」，幣別為元。它的訂單流程有四個步驟——收單、審核、執行、交付——產能以「訂單／日」衡量。第一課算出的基準產能是收單 100、審核 40、執行 80、交付 90，系統吞吐量等於最小值 40 訂單／日；加派第二位審核人員後變成收單 100、審核 80、執行 80、交付 90，吞吐量提高到 80 訂單／日。本課從這個「改善後」的狀態出發。所有金額、人力配置與時間都是教學 example，不是任何真實公司的資料。

核心問題

本課要回答的核心問題可以拆成三個，而且三個都必須用數字回答，不能用感覺回答。

第一，邊界問題： 一個流程步驟該留在公司裡，還是交給外面的廠商？完成標準是：讀者能寫出一份自建與外包的全額成本比較，其中包含創辦人最常漏掉的三類成本（廠商管理工時、品質抽驗與例外處理、轉換成本），並且能說出「便宜的那一邊」在什麼情況下仍然不該選。

第二，規模問題： 當需求從 80 訂單／日長到 200 訂單／日，哪些步驟必須改變、要改變多少、以及哪些看起來合理的投入其實一點效果也沒有？完成標準是：讀者能逐步驟算出目標產能與所需人力，能證明對非瓶頸步驟加人的吞吐量增益是零，並能指出流程圖上沒有畫出來、但實際限制了規模的那個「隱形步驟」。

第三，危機問題： 當營運真的斷掉時，公司靠什麼運作？完成標準是：讀者能寫出一套嚴重度分級與對應的反應期望、能說明為什麼事件負責人不該是動手修復的人、能算出一次事件各階段的耗時，並能主持一次不指向個人的檢討。

先定義本課反覆使用的詞。

外包（outsourcing） 是把原本由公司內部人員執行的活動，改由外部組織依合約執行。它不是「請人來做」，而是把一段流程連同它的判斷權一起移到公司邊界之外。

服務水準（service level） 是合約中對服務品質的可衡量承諾。一條有效的服務水準必須同時具備三件事：一個可觀測的指標、一個明確的門檻、以及一個未達門檻時會發生的後果。缺少後果的那一條只是願望。

退出計畫（exit plan） 是在簽約之前就寫好的、關於「如何停止使用這家廠商」的具體安排，包含資料如何取回、交接期多長、以及在交接期間誰負責什麼。

瓶頸（bottleneck） 是一連串步驟中產能最低的那一個。系統吞吐量等於各步驟產能的最小值，因此只有提高瓶頸的產能才會提高吞吐量。這是第一課的核心算術，本課會把它推到規模化的情境。

事件（incident） 是一個已經或即將造成服務中斷、品質失效或損害的具體事態。事件負責人（incident owner） 是在事件期間擁有決策權、負責協調與對外溝通的單一角色。無責檢討（blameless review） 是事件結束後進行的、以「系統為什麼允許這件事發生」而非「誰做錯了」為主軸的復盤。

完整解釋

外包是邊界問題，不是採購問題

大多數創辦人第一次認真考慮外包，是因為看到一張報價單比自己的薪資成本低。這是錯的起點，因為它把一個關於公司應該由什麼組成的問題，降級成一個關於價格的問題。

交易成本這個概念給出正確的起點。公司之所以存在，是因為在某些活動上，透過內部指揮協調的成本低於透過市場逐次議價、簽約、監督與求償的成本。反過來說，當某個活動的市場交易成本夠低——規格清楚、品質可衡量、供應商夠多、換人不痛——把它留在公司裡就不再有優勢。外包的決策，本質上是在問這個活動落在公司邊界的哪一側。

實務上可以用三個判準判斷，三個都是「留下」的理由：

第一，這個活動是不是核心（core）？ 核心的定義不是「重要」——薪資發放很重要，但它不核心。核心指的是：這個活動的品質，直接決定客戶為什麼選你而不選別人。 順風物流的交付準時率如果是客戶選擇它的主要原因，那交付就是核心；如果客戶只在意價格與帳單正確，交付就未必是核心。

第二，這個活動是不是差異化（differentiating）？ 差異化問的是：如果競爭對手用同一家廠商做同一件事，你還剩下什麼？審核步驟裡的風險判斷，如果建立在多年累積的客戶行為資料上，外包出去等於把這份判斷交給一個同時服務你競爭對手的人。這不必然是災難，但必須是有意識的選擇。

第三，這個活動的規則是不是還在快速變動？ 這一點最常被忽略。合約的更新速度遠慢於流程的更新速度。一個每個月都要調整判斷規則的流程，如果外包出去，你會發現每一次調整都變成一次合約協商或一次變更請款單。變動快的流程外包，成本不是出現在報價上，而是出現在每一次改變上。

反過來，適合考慮外包的活動有三個共同特徵：標準化（做法可以完整寫下來）、可衡量（成果可以用少數幾個數字驗收）、非差異化（做得比別人好不會讓客戶多付錢）。

你不能外包一個你從來沒有定義過的流程

這是本節最重要的一句話，也是實務上最貴的一個錯誤。

外包合約的標的是「規格」。你交給廠商的如果是一份清楚的流程定義——輸入是什麼、判斷規則是什麼、輸出的合格標準是什麼、例外怎麼處理——廠商就能按規格報價、按規格執行、按規格被驗收。你交給廠商的如果是一句「幫我們處理交付」，那麼廠商繼承的是你的模糊，而且他會為這份模糊收費。

他收費的方式有三種，而且都不會出現在原始報價上。第一種是報價墊高：不確定範圍的工作，任何理性的廠商都會用較高的單價覆蓋風險。第二種是變更請款：每一次你說「這種情況應該這樣處理」，都是一次超出原規格的變更。第三種是最貴的——驗收爭議：因為沒有寫下合格標準，雙方對「做得對不對」沒有共同語言，於是每一次客訴都變成一次談判，而談判的時間成本全部由你這邊的營運主管承擔。

所以順序不能顛倒：先定義流程，再決定要不要外包。 而一旦你真的把流程定義清楚了，你往往會發現兩件事——第一，定義清楚之後，自己做的成本也下降了；第二，你現在有能力比較兩邊，而在此之前你只是在比較「已知的自己」與「未知的外面」。

第一課要求每個步驟都要有書面的品質標準，理由之一就在這裡：那份文件同時是內部管理工具與外包規格書。

廠商管理：四件必須在簽約前處理的事

把流程交出去之後，工作沒有消失，只是換了形狀。原本管人的工作變成管合約，原本看流程的工作變成看指標。以下四件事如果沒有在簽約前處理，之後都很難補救。

服務水準必須有門檻與後果。 「廠商應盡力維持良好的交付品質」不是服務水準，它無法被驗證也無法被執行。可執行的寫法是三段式：指標、門檻、後果。例如「每月準時交付率（以客戶簽收時間對照承諾時間計算）不低於 97%；低於 97% 但不低於 95% 時，當月服務費折讓 5%；低於 95% 時折讓 15%，且連續兩個月低於 95% 時本方得無償終止合約」。這三段裡最常被省略的是第三段，而沒有第三段的服務水準，在真正需要它的那一天完全沒有效力。要注意的是，折讓的金額通常遠小於失效造成的損失——服務水準的價值不在於補償，而在於它讓「不合格」成為一個雙方都承認的事實，並且觸發一個雙方都同意的程序。

退出計畫要在簽約前寫，不是在想走的時候寫。 想終止合約的那一天，你的談判籌碼最少。要在合約裡先寫明的至少有四項：終止的通知期與可終止的事由；終止後的交接期長度與期間的收費方式；資料交還的格式、範圍與期限；以及交接期間雙方各自的義務。缺了任何一項，你都可能被迫在「繼續忍受」與「立刻中斷服務」之間二選一。

資料可攜性（data portability）是退出計畫的技術基礎。 如果客戶名單、地址、歷史紀錄與品質資料只存在於廠商的系統裡，而且只能用他的介面查看，那麼你的退出計畫在物理上就不成立。要在合約中約定的是：資料的所有權歸屬、可匯出的格式（必須是通用、可機器讀取的格式）、匯出的頻率（不能只有終止時才給）、以及終止後廠商刪除資料的義務與證明方式。實務上最低限度的紀律是——定期把資料匯出到自己控制的地方，並且真的打開來確認它可以用。 一份從未被驗證過的備份，等於沒有備份。

集中風險（concentration risk）要被明確衡量。 集中風險有三個面向。第一是你對廠商的依賴：如果這家廠商明天停止服務，你多久能恢復？第二是廠商對你的依賴：如果你佔他營收的 40%，他在議價上會讓步，但他的財務健康也和你綁在一起。第三是廠商自身的集中：他是不是也把關鍵環節再外包給另一家？NIST 在說明事件回應的第三方角色時明確指出，把責任移轉給服務供應商是一種責任共擔模式（shared responsibility model），責任的劃分必須在合約中清楚定義，而且己方團隊必須知道資訊如何流動、由誰協調、以及對方有多大權限代表己方行動（NIST SP 800-61r3，2025-04）。同一份文件也提醒，服務供應商通常對客戶系統有較高權限、也可能接觸敏感資料，因此供應商內部人員或供應商本身被入侵的風險必須被考慮並處理。這是 fact，出自 authoritative source；把它套用到物流廠商而非資安廠商，是本課的推論（inference），但機制是相同的。

營運如何隨規模斷裂：四種失效與它們的門檻

「規模化」聽起來像是同一件事做得更多，但實際上不是。營運在成長過程中會發生性質上的斷裂，而且每一種斷裂都有一個大致可以預期的門檻。以下四種按出現順序排列。這些門檻是本課依機制所作的推論與教學 example，不是任何普遍成立的常數；重點在於機制與失效前的徵兆，而不是數字本身。

第一種：非正式協調停止運作。 五、六個人在同一個空間工作時，協調是免費的——你轉頭就能問，例外當場就能決定。這種模式的成本隨人數呈平方成長：n 個人之間的兩兩溝通對數是 n(n − 1) ÷ 2。6 個人是 15 對，16 個人是 120 對，37 個人是 666 對。人數變 2.3 倍，需要維持的溝通關係變 5.5 倍（本課「逐步推導」會完整驗算）。

實務上斷裂通常發生在十到十五人之間，也就是「不是每個人都還認識每個人在做什麼」的那個點。失效之前的徵兆非常具體：同一個問題被不同的人用不同的方式回答；有人做了一件已經有別人做過的事；新人到職第二週還在問「這件事要找誰」；以及會議變多但決定變少。看到這些徵兆時，需要的不是更多會議，而是把口頭默契寫成文件、把角色的決策權明確化——這正是流程當責與 role accountability 的用途。

第二種：創辦人變成瓶頸。 這一種最危險，因為它偽裝成勤奮。創辦人通常保留了一條「例外處理」的路徑：不尋常的訂單、憤怒的客戶、折扣的核准，都往他那裡送。只要例外比例固定，創辦人的絕對工作量就與訂單量成正比，因此必然存在一個訂單量，超過它創辦人就飽和。本課會把這個數字算出來，答案是 150 訂單／日——低於 200 訂單／日的目標，而且流程圖上完全看不到它。

失效前的徵兆是：決策的等待時間開始出現在流程指標裡（例如「待核准」佇列變長）；創辦人休假時吞吐量下降；以及部屬開始說「我等老闆回覆」而不是「我判斷是這樣」。最後一句話是最清楚的訊號，因為它代表決策權從來沒有真正被授出去。

第三種：沒有被寫下來的知識變成單點失效。 每個成長中的公司都有一兩位「什麼都知道的人」。在小規模時這是資產；在擴張時這是單點失效（single point of failure），原因有兩個。第一，這個人離職、生病或休假時，一整類判斷沒有人能做。第二，也是更常被低估的——擴張需要訓練新人，而訓練的來源就是這個人，於是他同時是產能的一部分與訓練的唯一通道。 訓練期間他自己的產出下降，於是擴張的第一個效果是吞吐量下降。本課會算出這個下降的幅度：從 80 訂單／日掉到 64 訂單／日，持續約 18 週。

失效前的徵兆是：某個步驟的品質在特定某個人請假的那幾天明顯變差；文件裡寫的是「依經驗判斷」而不是判斷規則；以及當你問「如果他今天離職，這件事誰做」時，答案是一個名字而不是一份文件。

第四種：交接數量成長得比人數快。 每一次工作從一個人手上移到另一個人手上，都是一次交接（handoff），而每一次交接都是一次資訊可能遺失、責任可能落空的機會。步驟之間的交接數由流程決定（四個步驟就是三次交接），但步驟之內的交接數隨人數成長：交付步驟從 6 人變成 14 人時，「這一單該給誰」這個問題從偶爾出現變成每天出現幾十次，於是要嘛新增一個調度角色（多一次交接），要嘛用規則自動分派（需要先寫下規則）。

失效前的徵兆是：出現「我以為他會做」這句話；同一份工作被做了兩次；以及開始需要一個人專門負責「追進度」。當一個職位的主要工作是追別人的進度時，那個職位的存在本身就是交接失效的證據。

這四種失效有一個共同結構：它們都不是因為某個人變差，而是因為原本有效的協調機制在新的規模下不再有效。這也是為什麼英雄瓶頸案例裡那位無所不能的營運負責人，在規模小時是公司最大的資產，在規模變大時成為公司最硬的天花板——他本人的能力一點也沒有下降。

危機運作節奏

危機處理的核心不是「更努力」，而是在事前就決定好，事中要用哪一套不同的規則。以下六項是一套最小可行的危機節奏，順序有意義。

第一，明確宣告危機開始與結束。 這聽起來像形式，但它處理一個真實的問題：如果沒有人說「現在開始是事件狀態」，每個人就會各自用平時的優先順序做事，而平時的優先順序在危機中是錯的。宣告要有一個明確的人（通常是當班的負責人，不必是最資深的人）、一個明確的時間戳記，以及一個明確的通報管道。結束同樣要宣告，否則團隊會長期停在高警戒狀態，下一次真正的事件就叫不動人。

第二，指定一位事件負責人，而且這個人不動手修復。 這是整套節奏裡最違反直覺、也最有效的一條。直覺會說：最懂系統的人應該立刻去修。問題是，最懂的人一旦開始修，他就無法同時回答「現在狀況怎樣」、決定「要不要先關掉這個服務」、以及通知客戶。結果是修復的人每三分鐘被打斷一次，而外面的人得不到任何資訊。

把兩個角色分開之後：事件負責人負責決策、協調、對內對外溝通、記錄時間軸；修復者負責技術動作，並且只向事件負責人報告。NIST 在列舉事件回應角色時，正是把「領導層」（監督事件回應、對高衝擊處置有決策權，例如是否關閉或重建關鍵服務）與「事件處理者」（確認事件、蒐集分析證據、排定處置優先順序、限制損害、找出根因、恢復運作）分開列示（NIST SP 800-61r3，2025-04）。這是 fact。把它推到「小公司也應該分開這兩個角色，而且事件負責人不該同時是修復者」，是本課的推論——理由是小公司的人更少，因此角色重疊的傷害反而更大。事件當責案例呈現的就是這個分工被實際建立後的變化。

第三，事前定義嚴重度分級與對應的反應期望。 分級的目的不是分類本身，而是讓「要不要把人從床上叫起來」這個問題在事前就被回答。NIST 明確把「排定事件優先順序、評估其嚴重度、啟動復原程序」的準則列為事件回應政策應包含的關鍵要素之一（NIST SP 800-61r3，2025-04）。以下分級是教學 example，不是任何標準的要求，各公司應依自身業務自訂：

級別	判斷準則	通報時限	指派負責人	溝通間隔
S1	服務全面中斷，或涉及客戶資料外洩	10 分鐘內	15 分鐘內	每 30 分鐘
S2	部分客戶受影響，或關鍵指標跌破警戒線	30 分鐘內	1 小時內	每 2 小時
S3	單一客戶受影響，有可行的暫時處置	當班次內	次一工作日	每日一次

分級要用可觀測的準則寫，不能用「嚴重」「重大」這種需要判斷的詞，否則在半夜三點沒有人能判斷。準則寫得好的測試是：一位到職三個月的員工，看著儀表板就能自己判斷級別，不需要打電話問人。

第四，即使沒有新消息也要按固定間隔溝通。 這一條幾乎總是被違反，理由聽起來很正當：「等有結果再說。」但沉默不是中性的——在資訊真空裡，接收者會自己填入最壞的猜測，然後開始自行打電話追問，而每一通追問電話都會打斷正在修復的人。固定間隔的更新即使內容是「仍在處理中，目前已排除 A 與 B 兩個原因，下次更新在十點十八分」，也比沉默有價值得多，因為它同時傳遞了三件事：有人在處理、進度是什麼、以及下一次何時會知道更多。

第五，先穩定，再診斷。 在事件當中，「為什麼會這樣」與「怎麼讓它停止傷害客戶」是兩個不同的問題，而且第二個優先。NIST 描述的事件回應生命週期把「控制、根除、復原」放在偵測與分析之後、事後活動之前，而其中控制（containment）的目的正是限制損害而非解釋損害（NIST SP 800-61r3，2025-04）。實務上這意味著：可以先回退到上一個已知可用的版本、先手動處理、先暫停受影響的功能——即使你還不知道原因。堅持要先找出原因才願意採取行動，是把自己的求知慾放在客戶的損失之前。 前提是：所有為了穩定而做的動作都必須被記錄，否則診斷階段會失去證據。

第六，事後做無責檢討。 見下一節。

無責檢討為什麼必須無責

事件結束後最自然的問題是「這是誰造成的」。這個問題必須被主動擋下來，理由不是體貼，而是它會得到錯的答案。

論證是這樣的。假設檢討的結論是「小王在部署前沒有檢查設定檔」。這個結論在事實上可能完全正確。但它隱含一個預測：換一個更小心的人，這件事就不會發生。而這個預測幾乎總是錯的——因為真正讓事件成為可能的，是系統允許一個未經檢查的設定檔被部署到正式環境。只要這個條件不變，下一個人在同樣的疲勞、同樣的時間壓力、同樣缺乏防呆的情況下，會犯同一個錯。一份找到了人的檢討，等於宣告下一次同樣的事件會再發生一次。

還有第二個、更隱蔽的代價：指責會關掉資訊來源。事件的完整經過只有當事人知道。如果說出真相的代價是被檢討，理性的人會少說一點、說晚一點、或者下一次乾脆不通報邊緣狀況。於是公司失去的不只是這一次的根因，而是往後所有的早期訊號。這是績效、誘因與文化所講的誘因機制在危機情境下的直接應用：你檢討什麼，就會得到什麼樣的通報行為。

無責不等於無責任（accountability）。兩者的差別是：無責檢討不追究個人過失，但它一定會產出具名的改善行動。一份合格的檢討報告至少包含五個部分：

1. 時間軸：從偵測到復原，每個關鍵時點與當時已知的資訊。特別要記錄「當時他們知道什麼」，而不是「事後我們知道什麼」。
2. 影響範圍：多少客戶、多久、可量化的損失。
3. 系統層面的根因：至少追問三層「為什麼」，而且每一層的答案都必須是關於機制或條件，不是關於人。
4. 改善行動：每一項都有一個負責人的名字、一個完成日期、以及一個可驗證的完成條件。
5. 驗證：這些行動完成後，用什麼方式確認同類事件真的被擋住了。

第四點是整份報告存在的理由。一份沒有產出具名改善行動的檢討，就只是一篇作文。 而第五點是最常被跳過的：改善行動被列出來、被指派、甚至被標記為完成，但從來沒有人驗證它真的有效。追蹤這些行動的完成率，本身就應該是營運節奏中每月要看的一個指標。

從治理的角度看，這件事不只是營運層的工作。OECD 的公司治理原則把風險管理與內部控制系統的完整性監督列為董事會的職責之一（OECD，G20/OECD Principles of Corporate Governance 2023，accessed 2026-07-31）；IFC 的公司治理方法論同樣把「控制環境」列為六大治理面向之一，並說明它涵蓋內部控制、風險管理、內部稽核與遵循機制，用以確保公司資產的妥善管理、營運有效性與報告正確性（IFC，accessed 2026-07-31）。這支持一個判斷：重大事件的檢討結論與改善行動追蹤，應該進入董事會層級的定期報告，而不是停在營運會議。IFC 同時強調公司治理沒有「一體適用」的做法，會依公司類型調整——這也提醒讀者，上述作法的具體形式需按自身規模裁量。

失敗替代方案

因為內部一團亂，所以決定外包。

這個決定在當時看起來不只合理，而且像是唯一負責任的選擇。順風物流的交付步驟長期是客訴來源：準時率在 88% 上下，每個月有二十幾件客訴，負責的主管已經換過兩任，流程文件停留在一年前的版本而且沒有人照著做。管理層開了三次會，每次都得到「要改善」的結論，但兩個月後指標沒有動。這時候一家外包廠商提出每訂單 210 元的報價，並且承諾 97% 的準時率。

支持外包的論證聽起來無懈可擊：我們顯然不擅長做這件事；廠商每天處理的量是我們的幾十倍，他們一定比我們懂；而且報價比我們現在的成本低。「我們做不好，所以交給做得好的人」在邏輯上完全成立——問題出在它的前提。

它失效的假設是：這個流程之所以做不好，原因在於執行的人不夠好。 實際上，準時率 88% 的成因有四項，而其中三項與執行無關。第一，接單時承諾的到貨時間是業務人員自行估算的，沒有依據實際運能；第二，「準時」的定義在業務、營運與客服三個團隊之間不一致（一個算出貨時間，一個算簽收時間，一個算客戶感知）；第三，例外訂單（改地址、改時間、指定時段）沒有標準處理方式，每一件都要問人；第四，才是執行本身的效率問題。

外包之後會發生什麼？前三項成因原封不動地跟著流程一起交出去了。業務仍然做出無依據的承諾，只是現在承諾的對象變成廠商的運能而不是自己的；「準時」的定義爭議變成合約爭議，而且現在有金錢後果，所以爭得更兇；例外訂單沒有標準，於是每一件都變成一次變更請款或一次驗收爭執。廠商承諾的 97% 是「依合約定義計算的準時率」，而合約定義是廠商起草的、對他有利的那一個。六個月後的結果很可能是：合約上的準時率達到 97%，客戶感知的準時率仍然是 88%，而公司多付了整合成本、管理工時與例外處理費用，同時失去了自己改善這個流程的能力與資料。

預警訊號有四個，任何一個成立就應該先暫停外包評估：

第一，你無法用一頁紙寫出這個流程的合格標準。 如果你寫不出來，你就無法驗收，也無法比較。

第二，近三個月沒有人量測過這個流程的實際指標。 沒有基準線，你事後無法判斷外包到底改善了什麼。

第三，當你問「這個流程為什麼做不好」時，得到的答案是關於人（「那個團隊執行力不好」）而不是關於機制。 這代表根因分析根本沒有做過，而未診斷的根因不會因為換一個執行者而消失。

第四，外包的動機在會議紀錄裡被描述為「解決問題」而非「調整邊界」。 用詞洩漏了思考方式：邊界決策會比較兩邊的全額成本與策略後果，解決問題則只是想讓麻煩離開視線。

正確的順序是：先把流程定義清楚、量出基準線、找出根因、做完那些不必外包也能做的修正，然後再比較自建與外包。 這個順序有一個附帶好處——做完前四步之後，自建的成本與品質通常已經改善，而你這時候的比較才是誠實的比較。

逐步推導

一、自建對外包的全額成本比較

情境與假設（教學 example）。 順風物流考慮把「交付」步驟外包。目前吞吐量 80 訂單／日，每年工作 250 日，因此年訂單量 80 × 250 = 20,000 訂單／年。所有金額單位為元，比較期間為一年，兩邊都以「支應 20,000 訂單／年」為相同的產出基準——沒有相同的產出基準，任何成本比較都沒有意義。

本課使用的全額負擔人力成本（fully loaded cost） 定義為：現金薪資 + 雇主端法定提繳與保險 + 設備與辦公空間分攤。一位交付人員的假設值為：月薪 45,000 元 × 12 = 540,000 元；雇主端提繳與保險以現金薪資的 20% 估計 = 108,000 元；設備與空間分攤 72,000 元。合計 540,000 + 108,000 + 72,000 = 720,000 元／年／人。一位營運主管的全額負擔成本假設為 1,200,000 元／年。（雇主端提繳項目與費率因地而異，20% 純為教學假設，見「地區差異」。）

自建（make）的年成本：

項目	計算	金額（元／年）
交付人員	6 人 × 720,000	4,320,000
車輛、油料與保養	3 台 × 260,000	780,000
系統與工具授權	—	180,000
管理負擔（主管 30% 工時）	1,200,000 × 30%	360,000
自建合計		5,640,000

驗算：4,320,000 + 780,000 = 5,100,000；5,100,000 + 180,000 = 5,280,000；5,280,000 + 360,000 = 5,640,000 元／年。 單位成本：5,640,000 ÷ 20,000 = 282 元／訂單。單位檢查：(元／年) ÷ (訂單／年) = 元／訂單，正確。

外包（buy）的年成本。 廠商報價 210 元／訂單，年度最低承諾量 18,000 訂單。

項目	計算	金額（元／年）
服務費	210 × 20,000	4,200,000
系統介接（一次性 600,000，攤三年）	600,000 ÷ 3	200,000
廠商管理工時	300 小時 × 600	180,000
品質抽驗與客訴處理	720,000 × 25%	180,000
例外自行補送	600 件 × 450	270,000
轉換準備（保留最小自有運能與資料匯出）	—	150,000
外包合計		5,180,000

三個中間計算需要說明：

廠商管理工時：一位營運主管每週 6 小時、一年 50 週 = 300 小時／年。主管的每小時成本 = 1,200,000 元／年 ÷ 2,000 小時／年 = 600 元／小時（2,000 小時為年工時假設）。因此 300 × 600 = 180,000 元／年。

品質抽驗與客訴處理：外包後仍須有人抽驗廠商的交付品質、處理客戶投訴、與廠商對帳與爭議。以一位人員 25% 工時估計：720,000 × 25% = 180,000 元／年。

例外自行補送：假設 3% 的訂單廠商無法處理（地址異常、指定時段、客戶臨時變更），須自行補送，每件成本 450 元。20,000 × 3% = 600 件；600 × 450 = 270,000 元／年。

驗算合計：4,200,000 + 200,000 = 4,400,000；+ 180,000 = 4,580,000；+ 180,000 = 4,760,000；+ 270,000 = 5,030,000；+ 150,000 = 5,180,000 元／年。 單位成本：5,180,000 ÷ 20,000 = 259 元／訂單。

比較結果：

差額 = 5,640,000 − 5,180,000 = 460,000 元／年，外包較便宜。 節省比例 = 460,000 ÷ 5,640,000 = 8.16%，約 8.2%。 單位差額 = 282 − 259 = 23 元／訂單。交叉檢核：23 × 20,000 = 460,000 元／年，與總額差異一致。

創辦人最常做的錯誤比較。 直覺的做法是拿服務費比自建總額：5,640,000 − 4,200,000 = 1,440,000 元／年，看起來省了 1,440,000 ÷ 5,640,000 = 25.5%。

被漏掉的成本是 200,000 + 180,000 + 180,000 + 270,000 + 150,000 = 980,000 元／年。交叉檢核：1,440,000 − 980,000 = 460,000 元／年，與正確差額一致。

被漏掉的比例 = 980,000 ÷ 1,440,000 = 68.06%，約 68%。表面上看到的節省，有三分之二會被這五項吃掉。 這五項有一個共同點：它們全都是「你這一邊」的成本，因此不會出現在任何一份廠商報價單上。

損益兩平價格。 除服務費以外的外包成本固定為 980,000 元／年，因此可負擔的服務費上限 = 5,640,000 − 980,000 = 4,660,000 元／年，換算單價 = 4,660,000 ÷ 20,000 = 233 元／訂單。交叉檢核：233 × 20,000 + 980,000 = 4,660,000 + 980,000 = 5,640,000 元／年，等於自建成本，正確。

目前報價 210 元，距離兩平點只有 23 元，緩衝為 23 ÷ 210 = 10.95%，約 11%。續約時漲價 11%，整個成本優勢就歸零。 這不是一個假想情境——續約時漲價是外包關係的常態，因為那時候你已經沒有自有運能了。

轉換成本讓這個決定更不對稱。 假設外包三年後必須收回自建，需要重新招募 6 位交付人員。依本課程群的招募成本模型（職缺廣告與工具 30,000 + 面試工時成本 120,000 + 到職與訓練 200,000 + 前三個月產出折減 250,000 = 600,000 元／人），重建成本 = 6 × 600,000 = 3,600,000 元，尚未計入重新購置車輛與重建系統。

用外包每年省下的 460,000 元來回收這筆一次性成本：3,600,000 ÷ 460,000 = 7.83 年。也就是說，如果外包關係在八年之內破裂，這個決定在財務上就是虧的。 而八年遠長於多數外包合約的實際壽命。

所以，便宜的那一邊不會自動勝出。 8.2% 的成本優勢，在下列任何一項成立時都應該被推翻：

• 交付是唯一直接接觸客戶的步驟。 如果客戶對公司的印象主要來自送貨員，那交付的品質就是品牌本身，而品牌品質不適合用服務水準條款遙控。
• 交付準時率是差異化的來源。 如果客戶選擇順風物流的理由就是準時，把它交給一家同時服務三家競爭對手的廠商，等於主動放棄這個差異。
• 資料的敏感度與可攜性。 收件人姓名、地址與收貨習慣是敏感資料，一旦交給廠商，資料保護責任、跨境傳輸限制與退出時的刪除義務都必須另行處理（見「地區差異」）。
• 兩平緩衝太薄。 11% 的緩衝加上 7.8 年的轉換回收期，代表這個決定的財務優勢很脆弱而後悔成本很高。
• 例外比例可能被低估。 例外自行補送這一項用了 3% 的假設。若實際是 6%，這一項變成 540,000 元／年，外包合計變成 5,180,000 + 270,000 = 5,450,000 元／年，優勢從 460,000 元縮到 190,000 元。單一假設的誤差就能吃掉六成的優勢，這代表結論對假設高度敏感，應該先量測真實的例外比例再決定。

反過來，如果這個步驟的答案是「客戶不在意誰送、只在意有沒有準時到，而且我們的判斷完全寫得出來」，那麼 8.2% 加上可變動成本結構（外包費隨量增減，自有人力不會）就是一個合理的外包理由。結論不由成本單方面決定，但沒有算清楚成本的策略討論同樣沒有價值。

二、需求從 80 成長到 200 訂單／日

起點狀態。 收單 100、審核 80、執行 80、交付 90，系統吞吐量 = min(100, 80, 80, 90) = 80 訂單／日。

人力配置假設（教學 example）。 各步驟的人均日產能：

步驟	人均產能（訂單／人／日）	目前人數	目前產能（訂單／日）
收單	25	4	100
審核	40	2	80
執行	20	4	80
交付	15	6	90
合計	—	16	吞吐量 80

驗算：25 × 4 = 100；40 × 2 = 80；20 × 4 = 80；15 × 6 = 90。與基準一致。注意審核的 2 人正對應第一課「加派第二位審核人員」的動作（基準時 1 人 × 40 = 40 訂單／日）。

目標狀態的產能需求。 系統吞吐量要達到 200 訂單／日，代表每一個步驟的產能都必須至少 200 訂單／日——因為吞吐量取最小值，任何一個步驟低於 200，整體就低於 200。

步驟	目前	目標	需增加	倍數	目標人數	需增人數
收單	100	200	100	2.00	200 ÷ 25 = 8	4
審核	80	200	120	2.50	200 ÷ 40 = 5	3
執行	80	200	120	2.50	200 ÷ 20 = 10	6
交付	90	200	110	2.22	200 ÷ 15 = 13.3 → 14	8
合計	—	—	450	—	37	21

驗算：增加的步驟產能 100 + 120 + 120 + 110 = 450 訂單／日；增加的人數 4 + 3 + 6 + 8 = 21 人；目標人數 8 + 5 + 10 + 14 = 37 人，且 16 + 21 = 37，一致。交付的 200 ÷ 15 = 13.33 人必須無條件進位成 14 人，因為人不能分割；14 人的實際產能是 14 × 15 = 210 訂單／日，高於需求。

第一個結論：四個步驟全部都要改，沒有例外。 在 80 訂單／日的狀態下，只有審核與執行兩個步驟是限制；到了 200，收單與交付也不夠了。這說明瓶頸不是一個固定的位置，而是一個隨規模移動的位置。

第二個結論：為了讓系統多產出 120 訂單／日，必須增加 450 訂單／日的步驟產能。 比值 450 ÷ 120 = 3.75。每一單位的系統吞吐量成長，需要 3.75 單位的步驟產能成長。這個比值大於 1 的原因是：吞吐量取最小值，所以「補齊落後的步驟」這件事本身不產生吞吐量，只是讓其他步驟的提升能夠生效。

第三個結論：人力成長 2.31 倍，低於需求成長的 2.5 倍。 37 ÷ 16 = 2.31。看起來像規模經濟，但原因並不光彩：起點狀態的收單（100）與交付（90）都高於吞吐量 80，也就是原本就有閒置產能。擴張把這些閒置吃掉了。(100 − 80) + (90 − 80) = 30 訂單／日的閒置產能被利用，這就是「規模經濟」的全部來源。閒置只能被吃掉一次；下一次從 200 成長到 400 時，所有步驟都是滿載的，人力就會接近等比例成長。 把一次性的閒置回收當成可持續的規模經濟，是擴張預算被低估的常見原因。

成本： 新增 21 人的年度經常性成本 = 21 × 720,000 = 15,120,000 元／年；一次性招募成本 = 21 × 600,000 = 12,600,000 元。這兩筆數字必須同時進入現金規劃——一次性成本發生在前，收入成長發生在後，這正是跑道與財務控制要處理的時間落差。

三、對非瓶頸步驟加人，效果是零

這是本課程群最重要的一個算術，值得用數字把它變得無可爭辯。

情境 A：只擴充收單。 假設管理層決定「先從最容易招募的步驟開始」，把收單從 4 人增加到 8 人。

新狀態：收單 200、審核 80、執行 80、交付 90。 吞吐量 = min(200, 80, 80, 90) = 80 訂單／日。

增益 = 80 − 80 = 0 訂單／日。 付出的代價：一次性招募 4 × 600,000 = 2,400,000 元，年度經常性 4 × 720,000 = 2,880,000 元。

換算成每單位增益的成本：2,880,000 ÷ 0 是未定義的——不是「很貴」，而是沒有任何產出可以分攤這筆錢。這四位新人不是能力不足，他們每天都很忙，而且收單這個步驟的所有指標（處理量、速度、錯誤率）都會變好看。這正是這個錯誤如此持久的原因：局部指標全部改善，系統指標一動也不動。 如果營運節奏裡看的是各步驟的局部指標而不是系統吞吐量，這個錯誤可以持續好幾季而不被發現。

情境 B：只擴充審核。 這是更微妙的一種錯誤，因為審核在基準狀態下確實是瓶頸。把審核從 2 人增加到 5 人（產能 200）：

新狀態：收單 100、審核 200、執行 80、交付 90。 吞吐量 = min(100, 200, 80, 90) = 80 訂單／日。

增益仍然是 0。 原因是改善後的狀態有兩個步驟同時在 80（審核與執行），而吞吐量取最小值——只解除其中一個，另一個立刻接手成為瓶頸。第一課在提到「加派第二位審核人員後有兩個步驟同時是 80」時就埋下了這個伏筆：當兩個步驟並列最低時，下一次改善必須同時處理兩個，否則和什麼都沒做完全一樣。

這裡有一個對第一課的重要修正：在基準狀態（審核 40）時，「只改審核」是唯一正確的動作，把 40 提到 80 讓吞吐量從 40 翻倍到 80。同樣的動作在改善後的狀態下，效益是零。同一個動作在不同狀態下的價值可以從「翻倍」變成「歸零」，所以每一次改善之後都必須重新計算瓶頸在哪裡。 依上一次的結論行動，是規模化最常見的失誤。

情境 C：依序解除，看吞吐量如何前進。 把 200 訂單／日拆成四個階段，每個階段解除一個限制：

階段	動作	狀態（收單／審核／執行／交付）	吞吐量	增益
起點	—	100 / 80 / 80 / 90	80	—
一	審核與執行同時提到 200	100 / 200 / 200 / 90	90	+10
二	交付提到 210（14 人）	100 / 200 / 200 / 210	100	+10
三	收單提到 200	200 / 200 / 200 / 210	200	+100

驗算：階段一 min(100, 200, 200, 90) = 90；階段二 min(100, 200, 200, 210) = 100；階段三 min(200, 200, 200, 210) = 200。總增益 10 + 10 + 100 = 120，且 80 + 120 = 200，一致。

這張表是本課最重要的一張表。 它顯示：投入最大的兩個階段（一與二，合計增加 9 人、經常性成本 9 × 720,000 = 6,480,000 元／年）只換來 20 訂單／日；而最後一個階段（增加 4 人、4 × 720,000 = 2,880,000 元／年）換來 100 訂單／日。

階段一與二的每單位增益成本 = 6,480,000 ÷ 20 = 324,000 元／年／（訂單／日） 階段三的每單位增益成本 = 2,880,000 ÷ 100 = 28,800 元／年／（訂單／日）

相差 324,000 ÷ 28,800 = 11.25 倍。但這不代表應該只做階段三——只做階段三的話，狀態是 200 / 80 / 80 / 90，吞吐量仍然是 80，增益為零。這四個階段是一個不可分割的包裹，它的價值只在全部完成時才實現。

這個結構有一個殘酷的管理後果：擴張計畫在完成之前，看起來一直像是失敗的。 花了 6,480,000 元，吞吐量只從 80 到 90（+12.5%）。如果在這個時點有人要求「暫停看看成效」，計畫就會在最沒有說服力的位置被砍掉，而已經投入的錢完全無法回收。所以規模化計畫在提案時就必須把這張表附上，把「中途的成效會很難看」寫進預期，而不是等它發生時才解釋。 這也是營運節奏中「先講清楚會看到什麼」這條紀律的價值所在。

四、流程圖上沒有畫的第五個步驟：創辦人

假設創辦人保留了例外核准權：5% 的訂單需要他親自決定（大額折扣、特殊路線、爭議客戶），每件平均佔用 12 分鐘，而他每天最多能撥出 90 分鐘處理這件事——其餘時間必須留給客戶、募資、招募與策略。

創辦人每日可處理件數 = 90 分鐘 ÷ 12 分鐘／件 = 7.5 件／日 對應的訂單量上限 = 7.5 件／日 ÷ 5% = 150 訂單／日

交叉檢核：150 訂單／日 × 5% = 7.5 件／日；7.5 × 12 = 90 分鐘。一致。

所以真實的系統是五個步驟，不是四個：

吞吐量 = min(收單 200, 審核 200, 執行 200, 交付 210, 創辦人 150) = 150 訂單／日

花了 12,600,000 元一次性與 15,120,000 元經常性把四個步驟都擴充到 200 之後，實際吞吐量是 150，而不是 200。 目標的達成率是 150 ÷ 200 = 75%，缺口 50 訂單／日，而這個缺口在任何一張流程圖上都看不見。

現況檢查：在 80 訂單／日時，80 × 5% × 12 = 48 分鐘／日，只用掉創辦人配額的 48 ÷ 90 = 53%。所以今天完全沒有問題，而且會一直沒有問題，直到某一天突然全部都是問題。 這正是「創辦人瓶頸」難以提早發現的原因：它沒有漸進的惡化，只有一個飽和點。飽和點就是 150 訂單／日，可以在事前算出來。

解除的方式有三種，可以疊加，效果都可以量化：

• 降低例外比例。 把 5% 降到 2%（把最常見的三類例外寫成規則交給第一線判斷）：上限變成 7.5 ÷ 2% = 375 訂單／日。
• 縮短單件處理時間。 把 12 分鐘降到 6 分鐘（提供決策所需資訊的標準格式，不必來回問）：(90 ÷ 6) ÷ 5% = 15 ÷ 5% = 300 訂單／日。
• 把核准權授出去。 例如金額 20,000 元以下的例外由營運主管決定，只有超過門檻的才上呈。若這樣可以濾掉 70% 的例外，創辦人實際承接的比例是 5% × 30% = 1.5%，上限變成 7.5 ÷ 1.5% = 500 訂單／日。

三種手段中，第三種最有效但也最需要配套——它要求事前寫下核准準則，而且要求創辦人接受「有些決定會和我自己會做的不一樣」。這是授權與當責的核心，也是英雄瓶頸案例中最終沒有被跨過的那一步。

五、擴張期間吞吐量會先下降

最後一段推導處理一個違反直覺、但幾乎必然發生的現象。

審核步驟要從 2 人擴到 5 人，需要訓練 3 位新審核人員。假設（教學 example）：判斷規則從未被完整寫下來，訓練必須由現任資深審核人員一對一進行；每位新人需要 6 週才能獨立作業；一次只能帶一位；訓練期間，資深審核人員自己的產出降為原本的 60%。

訓練總長度： 3 人 × 6 週 = 18 週，18 週 × 5 工作日／週 = 90 工作日。

訓練期間的審核產能： 資深人員 40 × 60% = 24 訂單／日；另一位資深人員維持 40；新人在訓練期間視為零產出（保守假設）。 審核產能 = 24 + 40 = 64 訂單／日。

訓練期間的系統吞吐量： min(100, 64, 80, 90) = 64 訂單／日。

吞吐量下降 = 80 − 64 = 16 訂單／日，降幅 16 ÷ 80 = 20%。

累計損失： 90 工作日 × 16 訂單／日 = 1,440 訂單。若每訂單毛利為 120 元（教學假設，實際值應依毛利與單位經濟計算），損失的毛利 = 1,440 × 120 = 172,800 元。

驗算：3 × 6 = 18；18 × 5 = 90；40 × 0.6 = 24；24 + 40 = 64；80 − 64 = 16；90 × 16 = 1,440；1,440 × 120 = 172,800。全部一致。

這 172,800 元是「知識沒有被寫下來」的價格，而且它只是本次擴張的一次性帳單，不含前面提到的、每一次有人請假時的品質波動。

如果判斷規則被寫成文件與範例集，訓練可以並行（三人同時訓練）而且資深人員的產出折減降到 20%： 訓練長度 = 6 週 = 30 工作日（三人並行） 審核產能 = 40 × 80% + 40 = 32 + 40 = 72 訂單／日 吞吐量 = min(100, 72, 80, 90) = 72；下降 8 訂單／日 累計損失 = 30 × 8 = 240 訂單，毛利損失 240 × 120 = 28,800 元

節省 = 172,800 − 28,800 = 144,000 元，減少 144,000 ÷ 172,800 = 83.3%。

把判斷規則寫下來這件事，在這次擴張中的價值是 144,000 元。 這個數字之所以重要，是因為「寫文件」永遠排不進優先順序——它沒有截止日、沒有客戶在等、也沒有人會因為沒寫而立刻受罰。把它的價值算出來，是唯一能讓它進入排程的方法。要完整練習本課的三組計算，請完成營運系統設計練習。

六、一次事件的時間軸與各階段耗時

事件時間軸（教學 example，S1 級別）：

時點	事件	累計分鐘
09:12	偵測	0
09:18	通報	6
09:25	指派事件負責人	13
10:02	緩解（客戶影響停止擴大）	50
11:30	復原（服務完全回復）	138

驗算累計值：09:12 → 09:18 = 6 分；09:12 → 09:25 = 13 分；09:12 → 10:02 = 48 + 2 = 50 分；09:12 → 11:30 = 120 + 18 = 138 分。全部與表列一致。

各階段耗時：

偵測→通報 = 6 分；通報→指派 = 13 − 6 = 7 分；指派→緩解 = 50 − 13 = 37 分；緩解→復原 = 138 − 50 = 88 分。 交叉檢核：6 + 7 + 37 + 88 = 138 分，等於總時長，一致。

讀這張表的方法，是問每一段的耗時是被什麼決定的：

• 偵測→通報（6 分） 由監控與通報管道決定。這一段如果是幾十分鐘，代表偵測靠人工發現而非系統告警。
• 通報→指派（7 分） 由待命安排決定。這一段長，代表沒有明確的當班負責人，時間花在找人上。合計 13 分鐘完成指派，符合上表 S1 級別「15 分鐘內指派」的期望。
• 指派→緩解（37 分） 由準備程度決定，不是由能力決定。有沒有可以一鍵回退的版本、有沒有手動處理的備援流程、有沒有寫好的處置手冊，決定了這 37 分鐘是 10 分鐘還是 3 小時。
• 緩解→復原（88 分） 通常是最長的一段，而且這是正確的。緩解之後客戶已經停止受害，剩下的工作可以在較低壓力下謹慎完成。如果一家公司的緩解與復原時間幾乎相同，通常代表它沒有「先穩定」的能力，只能直攻根因。

溝通次數。 若依 S1 級別承諾每 30 分鐘更新一次，從 09:18 通報起算至 11:30 結案：排定更新為 09:18、09:48、10:18、10:48、11:18，共 5 則；再加一則 11:30 的結案通知，共 6 則。注意 11:18 之後的下一個排定時點 11:48 已超過結案時間，因此不發。

溝通涵蓋期間 = 138 − 6 = 132 分鐘，132 ÷ 30 = 4.4，向下取整得 4 個完整間隔，加上起始的那一則 = 5 則排定更新，與逐一列舉的結果一致。

其中至少有兩則的內容會是「仍在處理，尚無新結論」——而它們正是這套紀律最有價值的部分。 沒有它們，10:48 到 11:30 之間的 42 分鐘沉默，會讓每一位客戶自行判斷公司是不是已經放棄了。

常見誤解

「外包比較便宜。」 這句話比較的是廠商報價與自建總成本，而這兩個數字不在同一個基礎上。廠商報價只涵蓋執行；自建總成本涵蓋執行、管理、品質控制與例外處理。本課的例子中，把這些補回來之後，1,440,000 元的表面節省縮成 460,000 元，被漏掉的 980,000 元佔了 68%。而且外包會新增自建沒有的成本類別——介接、驗收、爭議處理與轉換準備。正確的說法是：外包可能比較便宜，但只有在流程已被定義、成本已被全額計算、且轉換成本已被納入的前提下，這個結論才成立。 在本課的例子裡，8.2% 的優勢加上 7.8 年的轉換回收期，讓它成為一個結論脆弱的決定，而不是一個明顯的決定。

「危機時要先找出誰的錯。」 這個誤解有兩個層面。第一，在事件當中追究責任會直接延長事件——被質疑的人會開始防衛與解釋，而不是報告事實。第二，在事件之後以個人為結論的檢討，會得到錯的答案：讓事件成為可能的是系統條件，而不是個人的注意力。找到了人的檢討，等於預言了下一次同樣的事件。它還有一個複合傷害——指責會讓通報變少，於是公司失去所有的早期訊號。這句話唯一可能成立的特殊情況是蓄意的不當行為（例如刻意規避控制、隱匿事實），那屬於紀律程序而非事件檢討，兩者必須用不同的流程處理，也不該在同一份文件裡混談。

「規模變大只要多請人。」 三個層次都錯。第一，加人如果加在非瓶頸步驟，吞吐量增益是零——本課算出把收單從 4 人加到 8 人，花費 2,880,000 元／年，吞吐量從 80 變成 80。第二，即使加在瓶頸，如果有兩個步驟並列最低，只解除一個仍然是零。第三，人數本身會製造新的問題：溝通對數從 16 人的 120 對變成 37 人的 666 對，成長 5.55 倍，遠快於人數的 2.31 倍。加人解決的是產能問題，但規模化的困難有一半是協調問題，而加人會讓協調問題變得更嚴重。

「事後檢討就是寫報告。」 報告是副產品，不是目的。檢討的產出是具名的、有完成日期的、有可驗證完成條件的改善行動，加上一個確認這些行動真的有效的驗證步驟。一份沒有改善行動的報告，唯一的功能是證明開過會。判斷檢討品質的方法只有一個，而且要等三個月後才能用：同類事件有沒有再發生？ 如果有，上一次的檢討就是失敗的，不管報告寫得多完整。另一個常見的變形是：改善行動被列出來、被指派、被標記為完成，但沒有人驗證它擋住了什麼——這在形式上完成了，在效果上等於沒做。

「服務水準協議簽了就有保障。」 服務水準的效力取決於三件事，缺一不可：指標是否可由你這一邊獨立觀測（如果只能看廠商提供的報表，你無法驗證）；定義是否精確到沒有爭議空間（「準時」以出貨時間或簽收時間計算，結論可能差好幾個百分點）；以及未達標的後果是否真的會被執行。而且要認清楚：折讓金額幾乎總是遠小於失效造成的損失。 本課的例子中，5% 的月費折讓約是 4,200,000 ÷ 12 × 5% = 17,500 元，而一個月的交付失控可能造成的客戶流失遠不止於此。服務水準的真正價值不是補償，而是把「不合格」變成一個雙方都承認的事實，並觸發一個雙方事前同意的程序。

「事件時應該由最懂的人指揮。」 最懂的人應該去修，而指揮應該是另一個人。原因是這兩個角色的工作在時間上互相排斥：指揮需要持續接聽、回覆、決定與對外說明，而修復需要不被打斷的專注。讓同一個人做兩件事的結果是兩件都做不好——修復被每三分鐘打斷一次，而外面的人得不到任何資訊。事件負責人不需要是技術上最強的人，他需要的是決策權、對業務影響的判斷力，以及維持節奏的紀律。

「等有明確結論再對外說明比較負責。」 沉默不是中性的。在資訊真空中，接收者會填入最壞的猜測，然後開始自行追問，而每一通追問都會打斷正在修復的人——於是沉默不但沒有省下時間，還延長了事件。 負責任的做法是按固定間隔說明「目前知道什麼、不知道什麼、下次何時更新」，並且明確區分已確認的事實與尚未確認的推測。承認「我們還不知道原因」不會損害信任；讓客戶在四十分鐘的沉默後自己發現問題才會。

實務檢查表

• 針對每一個考慮外包的流程，先寫出一頁的流程定義：輸入、判斷規則、輸出合格標準、例外處理方式。寫不出來就暫停外包評估，先完成定義。
• 用「核心、差異化、變動速度」三個判準各給出書面答案，任何一項為「是」時，把外包提案改為「先自建並改善」。
• 量出這個流程近三個月的實際指標作為基準線，並留存數據；沒有基準線時不進行外包比較。
• 完成一份自建對外包的全額成本表，兩邊使用相同的產出基準，且外包一側必須包含介接攤提、廠商管理工時、品質抽驗與客訴處理、例外自行處理、轉換準備五項。
• 算出外包的損益兩平單價與緩衝比例；緩衝低於 15% 時，在提案中明確標示「續約漲價即失去優勢」的風險。
• 算出反向轉換成本（重新招募與重建的一次性金額）與其回收年數，並與合約期長度並列比較。
• 每一條服務水準都寫成「指標 + 門檻 + 後果」三段式，並確認指標可由己方獨立觀測；只有廠商能提供的指標一律另設交叉查核方式。
• 在簽約前完成退出計畫，至少涵蓋終止事由與通知期、交接期長度與收費、資料交還的格式與期限、廠商刪除資料的義務與證明。
• 每季實際執行一次資料匯出並打開驗證可用性，記錄執行日期與驗證人。
• 列出集中風險三面向的現況：己方對廠商的依賴（恢復自主所需時間）、廠商對己方的依賴（營收佔比）、廠商是否再外包關鍵環節。
• 依現有人均產能，逐步驟算出目標訂單量所需的產能與人數，並確認每一個步驟都達標；任何一個步驟未達標時，不得宣稱系統可以支撐目標量。
• 每次改善之後重新計算瓶頸位置；出現兩個步驟並列最低時，把它們寫成同一個必須一起處理的項目。
• 在擴張提案中附上分階段吞吐量表，事先寫明中途階段的增益會很低，並約定不以中途數字作為中止依據。
• 算出創辦人（或任何保留例外核准權的人）的飽和訂單量：每日可用分鐘 ÷ 每件分鐘 ÷ 例外比例，並與目標訂單量比較；飽和量低於目標時，先處理授權再開始招募。
• 列出每一個「只有一個人會做」的判斷，為每一項指定一個文件化的截止日；未完成文件化前，不把該步驟排入擴張計畫。
• 在擴張的現金規劃中，同時列入一次性招募成本、經常性人力成本，以及訓練期間的吞吐量下降造成的毛利損失。
• 建立書面的嚴重度分級表，每一級都用可觀測的準則定義，並註明通報時限、指派時限與溝通間隔；用「到職三個月的員工能否自行判斷級別」測試準則。
• 在事件流程中明訂事件負責人與修復者為不同的人，並寫下事件負責人的決策權限範圍（可以自行決定停用哪些功能、可以自行對外發布哪些內容）。
• 準備一份對外溝通範本，含「已確認的事實／尚未確認的推測／下次更新時間」三個固定欄位，並規定即使無新進展也必須按時發出。
• 每次事件後在五個工作日內完成無責檢討，產出時間軸、影響範圍、系統層面根因、具名且有完成日的改善行動、以及驗證方式五個部分。
• 把改善行動的完成率與逾期件數列入月度營運檢視，並把重大事件的檢討結論與行動追蹤納入董事會定期報告。
• 每季檢查一次：過去三個月是否有同類事件重複發生；若有，重新檢討上一次的根因分析是否停在個人層面。

地區差異

本課的算術與機制在任何地方都成立。瓶頸取最小值、非瓶頸加人增益為零、溝通對數的平方成長、全額成本比較的結構、事件角色分離與無責檢討的邏輯——這些都不依賴任何國家的法律。它們是機制，不是規則。

但外包與規模化牽涉到的制度性規則不是全球通用，而且差異極大、變動頻繁。以下各項必須逐案查核（as-of 2026-07-31）：

第一，共同雇用與連帶責任的風險。 把一段流程外包出去，不代表雇主責任也一併移轉。許多法域對「派遣」「承攬」「勞務外包」有不同的定性，而定性通常取決於實質的指揮監督關係而非合約上的名稱。如果你直接指揮廠商的人員、安排他們的班表、決定他們的工作方法，在某些法域可能被認定為實質雇主或共同雇主，因而承擔薪資、保險、職災或資遣方面的責任；在另一些法域則可能對要派單位課予連帶或補充責任。國際勞工組織把「多方雇用關係」「偽裝的雇用關係」與「依賴性自營作業」並列為非典型雇用的類型，並指出各國的規範途徑不同，因而另外維護「就業保護法規資料庫」與「工作條件法規資料庫」供跨國比較（ILO，accessed 2026-07-31）。這正說明這一類問題的答案是「依國家而定」，不存在一個可以套用的通則。

第二，工作者身分認定的判準本身因地而異。 受僱者與獨立承攬人的區分標準、預告期間、終止事由、試用期、工時、最低報酬、競業禁止的可執行性與法定給付，各法域的規定差異巨大且經常修法。本課完全不提供任何一地的具體規則，所有這類問題請對照雇傭與承攬的地區差異查核 jurisdiction 與 as-of 日期。

第三，跨境外包會同時觸發資料傳輸與勞動法兩組問題。 把交付資料（收件人姓名、地址、聯絡方式、收貨紀錄）交給位於另一個法域的廠商，通常涉及個人資料的跨境傳輸，可能需要特定的法律基礎、契約條款、影響評估或主管機關程序；同時，如果廠商在當地僱用人員為你工作，還可能涉及當地的勞動、稅務與常設機構認定問題。這兩組問題的答案在不同法域完全不同，也可能在同一法域內因產業別而不同。

第四，事件通報義務有法定期限，而且期限因事件類型與法域而異。 涉及個人資料外洩、關鍵基礎設施中斷或特定產業（金融、醫療、電信）的事件，許多法域訂有對主管機關或當事人的通報義務與時限。本課的嚴重度分級表中的「通報時限」指的是公司內部的通報，與法定對外通報義務是兩回事，必須分別規劃——把內部節奏誤當成法定義務，可能導致逾期未報。

第五，合約條款的可執行性因地而異。 責任限制上限、懲罰性違約金、資料所有權的約定、以及終止條款，在不同法域的可執行程度不同；有些法域會限制違約金的額度，有些會對定型化條款有特別的審查。一份在甲地完全有效的合約範本，搬到乙地可能有數條無效。

因此，本課出現的所有金額、比率、人力配置、時限與分級門檻都是教學 example，不是任何地區的法定標準、最低要求或業界基準。凡是涉及雇主責任認定、派遣或承攬的合法性、跨境資料傳輸、法定事件通報期限或合約條款效力的具體問題，請就個案尋求當地合格的法律、稅務、勞動與資料保護專業協助，並在決定前確認資訊的 as-of 日期。特別提醒一個安靜但代價很高的錯誤：把外包合約簽好之後才發現指揮關係造成共同雇用風險，此時流程已經移轉、自有運能已經解散，補救的選項比簽約前少得多。 這類查核必須發生在簽約之前，而不是稽核之後。

資料來源

Incident Response Recommendations and Considerations for Cybersecurity Risk Management (NIST SP 800-61r3) 支持本課危機章節與廠商章節的數項具體主張。第一，事件回應角色的分工：該文件在列舉角色時，把「領導層」（監督事件回應、配置資源，並對高衝擊處置行動如關閉或重建關鍵服務擁有決策權）與「事件處理者」（確認事件是否發生、蒐集與分析證據、排定處置優先順序、限制損害、找出根因、恢復運作）分別列示——這支持本課「決策協調與技術修復是兩個不同角色」的說法。第二，嚴重度分級：該文件把「排定事件優先順序、評估嚴重度、啟動復原程序與維持或回復營運的準則」列為事件回應政策應包含的關鍵要素之一。第三，生命週期順序：該文件描述的既有生命週期模型將「控制、根除與復原」置於偵測與分析之後、事後活動之前，支持本課「先穩定、再診斷」的順序主張。第四，外包與責任共擔：該文件明確指出把部分責任移轉給服務供應商是一種責任共擔模式，責任劃分必須在合約中清楚定義，己方團隊必須了解資訊流動、協調方式與對方代表己方行動的權限，並須考慮供應商內部人員或供應商本身遭入侵的風險——這是本課廠商管理章節的直接依據。該文件於 2025 年 4 月發布，取代 SP 800-61r2。需要標明的邊界是：這份文件的範圍是網路安全事件，本課把同一套角色分工與生命週期邏輯套用到物流營運事件，屬於作者的推論（inference），理由是兩者在「不確定情境下的協調結構」上具有相同機制；此外，該文件並未使用「無責檢討（blameless review）」一詞，本課關於無責的論證是作者的推論，不是該文件的主張。

Non-standard forms of employment（ILO）支持本課「地區差異」章節的核心判斷。該頁把非典型雇用定義為偏離標準雇用關係的各種安排的統稱，並明確列舉「臨時性派遣工作與多方雇用關係」「偽裝的雇用關係與依賴性自營作業」等類型；同時它並未給出跨國統一的規則，而是指向「就業保護法規資料庫」與「工作條件法規資料庫」兩個比較性資源。這兩點合起來支持本課的主張：外包所產生的雇主責任與工作者身分問題，其答案由各國法制決定，不存在全球通用的規則。這是 fact；把它轉換成「簽約前必須查核當地的共同雇用與連帶責任風險」這項行動建議，是本課的推論。

IFC Corporate Governance Methodology Tools（International Finance Corporation）支持本課關於「事件與控制屬於治理層級議題」的判斷。該頁把「控制環境」列為六項治理參數之一，並說明它涵蓋內部控制、風險管理、內部稽核功能與遵循機制，用以確保公司資產的妥善管理、營運有效性、報告正確性以及對政策、程序與法規的遵循。該頁同時明確指出公司治理沒有「一體適用」的做法，方法論會依公司類型（上市公司、國營事業、家族企業、基金、金融機構與中小企業）調整——本課因此提醒讀者，董事會層級的事件報告與控制安排必須按自身規模裁量，而不是照抄大型公司的形式。

The responsibilities of the board（OECD，G20/OECD Principles of Corporate Governance 2023）支持本課「重大事件的檢討結論與改善行動應進入董事會層級」的主張，其依據是該原則將風險管理與內部控制系統完整性的監督列為董事會職責的一部分。這份文件是原則層級的國際文件，不是任何國家的法律；各地公司法對董事會職責的具體規定必須另行查核。

四份來源的共同邊界必須說明清楚：沒有任何一份支持本課的數字。 順風物流的產能、人均產能、薪資、廠商報價、例外比例、訓練時間與事件時間軸，全部是為教學設計的 example；其上的所有計算是作者依這些假設所作的算術推導（inference），可以被讀者重算與檢驗，但不能被當成任何真實公司或產業的基準值。特別是各項門檻——十到十五人的協調斷裂點、5% 的例外比例、12 分鐘的單件處理時間、11% 的兩平緩衝——都是為了讓機制可見而設定的假設，讀者應該用自己公司的實際數字重跑一次，而不是採用本課的數字。