🎯 什麼情境該想到我
當你「說不清楚自己在做的技術工作對公司有什麼用」、預算與人力永遠排在業務專案後面、
或需要跟財務長／高層溝通「為什麼要花錢在看不見的地方」時。
⚙️ 怎麼用（四欄表）
-
先拿到對方的業務目標：不是你猜的，是去問業務端負責人「你今年要達成什麼、什麼事會危及它」。書中 Bill 拿到的是市占率、平均訂單金額、獲利回復、資產報酬率這類 CFO 語言的指標。
-
畫出這張表，一列一個業務指標：
① 業務績效指標 ② 依賴哪些 IT 系統 ③ IT 出包會怎樣 ④ 靠什麼控制來防 掌握顧客需求 訂單輸入、庫存管理系統 資料不準、報表不即時、要重工 … 產品組合 訂單輸入系統 資料不準 … 欄位定義：第一欄是達成目標所需的業務能力與流程；第二欄是這些流程依賴的 IT 系統；第三欄是系統或資料可能出什麼錯；第四欄是你打算靠什麼控制去擋。
-
把 IT 的維運指標翻譯成業務指標的「前導指標」。書中的類比：預防性換機油與保養之於車隊，等同於預防性的廠商修補與變更管理之於 IT——沒人會為「換機油」興奮，但所有人都在乎「貨有沒有準時到」。
-
收斂成一句話講給高層聽：
「IT 帶來的維運風險，需要像其他業務風險一樣被管理。換句話說，它們不是 IT 風險，是業務風險。」
-
準備具體案例：找出過去「IT 出事實際害到哪個業務目標」的真實事件，帶著證據去談，別空泛講理念。
🧪 我實際套用的紀錄
- 2026-08-02：（待填）
⚠️ 注意 / 什麼時候不適用
- 這張表不能自己關起門來填。第一欄一定要從業務端訪談來，否則你只是把技術願望包裝成業務語言，對方一眼看穿。
- 反向的收穫同樣重要：書中 John 訪談稽核團隊後發現，有些他堅持多年的 IT 控制其實不需要，因為組織其他部分已經充分緩解了那個風險。這張表是用來「該加的加、該砍的砍」，不是拿來替既有工作背書。
- 它解決的是「溝通與定位」，不會讓交付變快——真正變快要靠流動面的工具。