一場工作坊，會議室裡有護理師、藥師、單位主管，還有我們品管室的人。螢幕上的共用表格有一整排欄位等著填，各專業要把自己熟悉的環節補進去。
第一個小時，沒有人填到任何一格。
因為卡在最前面那一步：這條流程到底有幾個步驟？
有人上台畫了五個框，很標準的教科書版本。護理師看了看說，第三個框裡面至少有七件事，而且不是同一個人做的。藥師說，第二個框跟第三個框中間還漏了一次交接——藥從藥局出去到病人身邊，中間會經過誰、在哪裡放過、放多久，那段完全不在圖上。
白板擦掉重畫，三次。
那時候我心裡有點急，覺得一個小時就這樣沒了。後來我改變想法了：那個小時不是浪費，它是這場工作坊裡唯一一件不能外包的事。
先把名詞交代掉。
HFMEA 是醫療照護失效模式與效應分析，一句話講完它在做的事：在事情出錯之前，把流程攤開，逐步問「這一步可能怎麼壞、壞了會怎樣、多常壞」。
它跟昨天那篇的方向剛好相反。根因分析是事後往回追，HFMEA 是事前往前推。它接近 pre-mortem，也接近威脅建模——在系統上線之前，逐個元件問「這裡會怎麼被打爛」。
今天只談第一步：把流程攤開。
因為在實務上，這第一步就是最難的一步，而且它難的地方不是資訊不足，是沒有人告訴你要切多細。
以下是一段簡化過的給藥流程，純粹為了說明用，不對應任何實際院內流程：
五步。看起來很完整，任何人都會點頭。
問題是——這五步之間，有幾次交接？
「切多細」這件事你不陌生。一個 service 該多大、一個 span 該多細、模組邊界劃在哪、一個 log event 記到什麼層級。
你也知道切錯的兩種代價：
HFMEA 完全一樣。而且第二種錯更常見，也更致命——條目一多，工作坊開不完，第三個小時之後所有人開始亂填分數，整份表的評分品質瞬間歸零。
顆粒度過細不是浪費時間，是會摧毀評分品質。 你拿到的不是一份更精細的分析，是一份更精細的亂數。
那要怎麼決定？這正是那種「靠資深的人一看就知道」的判斷。我試著把它拆開，結果它比想像中更拆得開——四條規則。
到這裡為止還是一堂品管課，所以我把它壓成一張表，接下來才是我真正想寫的。
| 規則 | 判準 |
|---|---|
| 一、角色一換就切 | 一個步驟只能有一個負責角色。角色換了還沒切，等於把一次交接藏進步驟內部——藏起來的交接不會被分析到 |
| 二、一步只有一族壞法 | 要為這一步寫三種完全不同的失效方式（弄錯對象、時間延誤、資訊遺漏），就是太粗，該拆 |
| 三、切到有介面為止 | 兩步之間必須存在一次真實的交接：一次系統寫入、一次口頭交班、一次電子任務轉派、一次等待。沒有交接的地方切開，只是在製造條目 |
| 四、停在還能被介入的層級 | 切到「伸手拿起藥盒」這種動作級，就沒有任何一條對策掛得上去。Day 13 那把尺說過，有用的對策要改得動環境；切到再往下就無策可施的那一層，就停 |
第三條是四條裡最重要的，而且它給了這篇真正想講的那句話：
你在 HFMEA 裡切的不是步驟，是交接。錯誤不住在步驟裡，錯誤住在交接處。
這句話對 IT 讀者不需要翻譯。你的 incident 有幾成發生在單一函式內部？幾乎沒有。它們發生在服務之間、發生在部署的那一刻、發生在兩個團隊對同一個欄位有不同理解的地方、發生在重試與逾時的時間差裡。
回到那條給藥流程。不看步驟，只看交接：
| 交接 | 從誰到誰 | 介面型態 |
|---|---|---|
| 醫囑送出 → 藥局接收 | 醫師 → 藥師 | 系統 |
| 醫囑修改或停用 → 藥局是否知道 | 醫師 → 藥師 | 系統 ＋ 時間差 |
| 調劑完成 → 送出藥局 | 藥師 → 運送 | 實體 |
| 藥品抵達單位 → 交給執行的人 | 運送 → 護理師 | 實體 ＋ 人 |
| 換班時尚未完成的給藥 | 護理師 → 護理師 | 口頭 |
| 給藥完成 → 系統紀錄 | 護理師 → 系統 | 系統 ＋ 時間差 |
（示意）
原本的五個步驟，變成六個交接。
而其中兩個——醫囑修改的時間差、換班時未完成的給藥——在五步版本裡根本不存在。它們不是步驟，它們是步驟之間的縫。
前一個是快照問題：藥師手上那份，是醫囑送出當下的樣子；醫師後來改的是原件。兩邊什麼時候重新對齊，流程圖上沒有任何一個框負責。
沒有人會在流程圖上畫一個框叫「換班」。但如果你問任何一個做過臨床的人，事情最容易出狀況的時刻是什麼時候，換班一定在前三名。
縫，才是事故住的地方。 而顆粒度切得對不對，決定的就是這些縫會不會出現在表上。
那讓 AI 來拆呢？它讀過的流程圖比任何一個人都多。
我試過，結果很一致，而且方向可以預測。
不給約束，它給你教科書版本。 五步，跟白板上第一次畫的那張幾乎一樣。原因不難猜：語料裡的流程圖絕大多數是簡報等級的粗顆粒——那是用來給人看懂的圖，不是用來找弱點的圖。
加一句「請詳細拆解」，它崩到動作級。 三、四十個步驟，包含「核對床號」「拿起藥盒」「確認藥品名稱」。
沒有中間檔位。它的顆粒度是被措辭驅動的，不是被用途驅動的——它在回應「詳細」這兩個字，而不是在回應「我要找得到弱點」這個目的。你要的那一格是 log level 裡的 INFO，它給你的只有 ERROR 跟 TRACE。
而更麻煩的是第三件事，這件事我覺得是本篇最重要的一段：
它拆的是文件裡的流程，不是現場的流程。
現場真正存在的那些節點——等醫師回電、藥品不足去隔壁單位借、系統當機改走紙本、有人在忙所以請旁邊的人幫忙看一下——不會出現在任何一份 SOP 裡。既然沒有被寫進文件，也就不在任何語料裡。
AI 拆出來的是被寫下來的流程，而事故發生在沒被寫下來的流程裡。
這句話幾乎就是這整個系列的縮影。規則寫得下來的那一半，早就被畫進流程圖了，也早就被系統擋住了。剩下的那一半沒有進文件，所以模型看不到，所以它拆出來的流程永遠是乾淨的、順的、每一步都成功的那個版本。
這是這篇的設計決策，而它的重點在順序。
我原本的做法很自然：讓 AI 先拆一版，人再修。否決了，而且理由不是它拆得不好。
理由是錨定。
一旦那張五步的圖被投影在會議室的牆上，工作坊就再也回不去了。所有人開始在它的框架裡討論細節——這一步要不要再細一點、那一步的敘述要不要改。沒有人會站起來說「這五個框的切法根本不對」。
人修 AI 的產出，修的是內容，很少會修結構。而顆粒度是結構。
這件事在 code review 上一樣：面對一支已經寫完的 PR，你會挑命名、挑邊界條件，很少會說「這個拆法整個不對，重來」。愈完整的東西，愈難被推翻。
這帶出一條我在整個系列裡對人機分工最重要的判斷：
AI 可以先做的事，是那些「錯了還看得出來」的事。顆粒度錯了看不出來，因為錯的東西不會出現在表上——它只是不在。
一條被漏掉的失效模式不會發出任何聲音。它不像一個錯誤的答案會讓你皺眉，它就只是不存在。這種錯誤沒有辦法靠事後審閱抓到，只能靠一開始就不要讓它發生。
所以順序反過來：
這一步 AI 的廣度是真的有價值：同一個交接點可以怎麼失敗，它鋪得比人快，也鋪得比人齊。
人切邊界，AI 填內容。 一句話講完。
流程一旦被固定成「角色 × 交接點」這種結構，有些原本做不到的事就順手了。
HFMEA 在實務上最大的問題，從來不是分析做得不夠好，是做完就放進抽屜。流程一改版，整份表就過期了，而沒有任何人有力氣重開一次為期三天的工作坊。所以多數 HFMEA 的生命週期，是評鑑前做一次，評鑑後歸檔。
但如果流程是結構化的，改版就可以 diff：這次動到的是哪兩個交接點？那就只有掛在那兩個節點上的失效模式需要重審，其他的沿用並標註「本次未重審」。重做的成本從「重開一次工作坊」降到「重跑兩個節點」。這一段我還沒實際跑過一輪改版，是我打算這樣做。
同一個結構也可以套到別的流程去——角色換掉、交接點換掉，但「在每個交接點內部展開失效模式」這件事的做法完全一樣。
把 HFMEA 從一份文件變成一個可以重跑的東西，這件事比讓 AI 多想出十條失效模式有價值得多。
前者改變的是這套方法在制度裡的位置，後者只是省了一個下午。
明天談 HFMEA 少掉的那一欄。它不是被忘記的，是被有意拿掉的——而當我們試著把它放回來，會問出一個對做系統的人來說很不舒服的問題：你的系統，看得見自己出錯嗎？
iThome鐵人賽
看影片追技術