概念地圖・事件風暴圖
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
事件風暴圖：四小時把跨部門的認知落差擠出來
一面牆貼滿橘色便利貼，四個小時之後，會議室安靜了幾秒。全公司第一次看見，「訂單成立」這四個字，在業務、倉庫、財務嘴裡指的是三個不同的時間點——業務算客戶簽回報價單那天，倉庫算揀貨單印出來那天，財務算款項入帳那天。中間差了兩天，於是每個月的帳都對不起來，已經對不起來三年。事件風暴圖（Event Storming）就是 Alberto Brandolini 設計來製造這種場面的工具：把一整條業務流程，拆成一串「已經發生的事」，按時間排在同一面牆上，讓所有人一次看完。
五層便利貼，一排一排往上下長
事件風暴的規矩少得有點粗暴：先只准貼一種便利貼，把所有「已經發生的事」按時間排完，再回頭補其他四層。下面這張表把圖上五排的職責寫成文字，順便標出每一層貼歪時，公司會出現什麼症狀。
| 層別 | 貼什麼・怎麼寫 | 貼歪了會出現的症狀 |
|---|---|---|
| 領域事件 | 業務上真的發生過、而且有人在乎的事實，動詞一律過去式：「訂單已成立」「款項已收訖」。 | 寫成「處理訂單」這種進行式，時間點就糊掉了，牆上再也對不出誰早誰晚。 |
| 命令 | 觸發那件事的動作，用祈使句：「建立訂單」「揀貨出庫」。一個命令對應一個事件。 | 命令找不到對應事件，代表這個動作做完什麼也沒改變，通常是儀式性的簽核。 |
| 角色／人 | 按下那個命令的人或系統帳號：業務、倉管、值班店長、排程程式。 | 整排都寫「系統」，等於承認沒人知道這步是誰在負責，出事只能找主管。 |
| 政策 | 事件發生後自動啟動的規則，念得出「每當……就……」：每當款項收訖就排入出貨。 | 政策藏在某個資深員工腦裡沒被貼出來，他請假那週流程就會停擺。 |
| 外部系統 | 我們喊不動、只能接的對象：金流、物流、電子發票平台、公部門介接。 | 把外部系統畫成內部流程的一格，排期時就會把別人的工作天當成自己的。 |
表上沒寫、但工作坊裡最值錢的是第六種便利貼：熱點。它斜貼在任何一張便利貼的角上，代表「這裡有人有異議，而且現在吵不完」。事件風暴真正的產出，是那幾張斜貼的熱點——牆會被拍照存檔然後遺忘，熱點會變成接下來兩個月的待辦。
每一層要通過的那一關
一、事件念出來要是「已經」。這條規定看起來龜毛，作用卻很實際：只要一張便利貼得加上「應該」「會」「通常」才通順，它就還停在願望那一層，代表沒有人真的確認過它發生。把它降級成待查，別讓它混進時間軸。自問：這張便利貼我念得出「⋯⋯已經完成了」嗎？
二、命令背後要指得出一個具名的人。職稱不算數，要指到那個真的會在星期三下午三點按下按鈕的人。指不出來，通常代表這個動作卡在兩個部門的縫裡，雙方都以為對方會做。自問：這個命令上禮拜是誰執行的，我叫得出名字嗎？
三、政策要能被念成「每當⋯⋯就⋯⋯」。念不順的多半有隱藏條件：「每當款項收訖就排入出貨（但金額超過十萬要等主管點頭）」。那個括號才是真規則，把它拆成第二張便利貼貼上去。自問：這條規則有沒有例外，例外由誰認定？
四、外部系統要標出「這一格我們喊不動」。外部系統的回應時間不歸我們管，卻常被排程當成自家的一天。把它單獨一層標出來，估時才會誠實。自問：這一格如果今天壞掉，我能打電話給誰？
五、爭議當場貼熱點，不留到會後私下講。工作坊最容易失敗的一刻，是有人皺了眉，然後把話吞回去。主持人的工作是把那個皺眉變成一張斜貼的紙。自問：剛剛那個沉默，有沒有變成牆上看得見的東西？
一條手搖飲訂單，走一遍牆上
- 先只貼事件：連鎖手搖飲總部找來加盟店長、外送平台窗口、材料撥補、行銷、財務，四十分鐘只准貼過去式。牆上很快出現「訂單已成立」「飲料已製作完成」「訂單已送達」「材料已撥補」「營收已入帳」。五個人第一次看見完整的一條線
- 第一個熱點：「訂單已成立」被斜貼了一張紙。店長說的是店裡機器叫號那一刻；外送平台窗口說的是平台派單成功那一刻；財務說的是平台次日對帳檔進來那一刻。同一個詞，三個時間點，最遠差了一天
- 補命令與角色：「材料已撥補」上面補命令時卡住了，沒有人按過任何按鈕——那是每週三系統自動跑的排程，寫排程的工程師去年離職。一條每週影響全店庫存的規則，沒有主人
- 補政策：「每當訂單送達就結算店鋪抽成」念出來時，行銷舉手：促銷檔期的抽成比例不一樣，這條規則實際上有兩個版本。兩個版本從來沒寫在同一份文件
- 標外部系統：外送平台被移到最下面一層。原本排程表把「平台對帳檔」當成自家可控的一步，實際上它每個月固定晚兩天。月結延遲的老問題，當場找到出處
四十分鐘的貼紙時間，換來三張熱點：一個名詞的三種定義、一條沒有主人的排程、一份有兩個版本的抽成規則。這三件事在牆出現之前，每一件都有人知道——店長知道自己的叫號時間、財務知道對帳檔晚到、行銷知道促銷有另一套算法。缺的從來不是資訊，是一個讓這些人同時站在同一面牆前的下午。事件風暴的價值就落在這個接縫上：它不生產新知識，它把散在五個人腦裡、彼此以為對方也懂的東西，攤成同一條時間軸上互相矛盾的紙條。矛盾一旦掛在牆上，就沒辦法再假裝不存在。以上為說明結構用的示意情境，僅供理解框架之用。
這面牆什麼時候會騙你
- 人沒到齊，那就只是一場技術會議。事件風暴的全部賭注押在「所有相關的人同時在場」。少了倉管，出庫那一段就會被業務憑印象貼完，而且貼得很順——因為沒有人在場反駁。牆看起來完整，落差原封不動留在原地。真正該問的是：那個最忙、最難約、最常說「你們決定就好」的人，願不願意站滿四個小時。
- 擠得出時間點落差，不一定擠得出定義落差。過去式規定很擅長暴露「什麼時候發生」的分歧，對「這個名詞到底指什麼」卻只有一半的力氣。四個人盯著同一張「客戶已流失」，各自心裡默念不同的判定條件，牆上照樣風平浪靜。主持人要多做一步：隨機點名兩個人，各自把那張便利貼的定義念出來，念完再決定貼不貼熱點。
- 牆貼得越漂亮，越沒人問「這步該不該存在」。把現況畫成一條乾淨的時間軸有種完成感，接著就會有人提議把它做成標準作業程序。但風暴的產出是一份爭議清單，SOP 是另外一場會議的事。整面牆最有價值的區域，往往是那幾格擠成一團、彼此蓋來蓋去的地方，因為那裡代表真實流程本來就亂。急著把它排整齊，等於把證據擦掉。
牆上沒有一張便利貼寫著「他為什麼要」
過去式是一條文法規定，也是一台測謊機。
逼所有人把系統講成「已經發生的事」，願望、規劃、我以為都會當場現形，藏在五個部門之間的認知落差才被擠出來——這是事件風暴最漂亮的一招，幾乎沒有別的工具做得到。可是同一條規定也劃出了它的邊界：這面牆畫得出系統裡發生了什麼，畫不出使用者為什麼非要它發生。從「訂單已成立」到「營收已認列」，每一張紙寫的都是我們做了什麼；沒有一張寫著他那天為什麼掏錢、為什麼是這一家、為什麼不是再等一個禮拜。一條流程可以貼得毫無矛盾、每個名詞都對齊、每條政策都有主人，然後整條線服務的仍然是一個沒人真的痛的需求。P.A.I.N. 之尺裡最前面那一格「誰在痛」，恰好是這面牆天生沒有的那一層。今晚可以做一件很小的事：翻出你手上那條流程最開頭的那個事件，在它左邊補貼一張空白紙，只寫一句話——「他為什麼會走到這一步」。寫不出來，那才是明天真正要處理的熱點。
常見問題
事件風暴一定要工程師參加嗎？
最早的用法是給軟體團隊釐清領域模型的，所以文獻裡工程師的比重很高。但那面牆上貼的全是業務語言，非技術人員反而是主力。純粹要對齊跨部門認知時，找齊真的會操作流程的人比找齊技術人員重要；如果接下來要動系統，再把工程師拉進來跑第二輪，讓他們對著同一面牆問「這一格資料從哪來」。順序顛倒的話，會議很快就會滑進資料表結構的討論，業務端的人會開始滑手機。
事件風暴圖和流程圖差在哪裡？
流程圖問「這件事怎麼做」，事件風暴問「這件事什麼時候算發生了」。前者的每一格是動作與判斷分支，畫得好就能拿去交辦與稽核；後者的每一格是既成事實，畫得好會浮出一堆彼此矛盾的紙。所以流程圖適合優化執行效率，事件風暴適合在動手優化之前，先確認大家講的是同一條流程。實務上常見的順序是先風暴、把熱點吵完，再把收斂後的共識畫成流程圖。
一場工作坊要開多久、幾個人？
常見的做法是半天到一天、八到十五人，一面至少八公尺長的牆。人數的關鍵在覆蓋：流程上每一段，都要有一個真的在做的人在場。時間短於三小時通常只夠貼完事件層，補命令與政策的階段被壓縮，熱點就吵不出來。若真的只約得到兩小時，寧可只做一段流程做深，別把整條線草草貼完——半條有熱點的牆，勝過一整條沒有人反對的牆。
遠端沒有實體牆，可以做嗎？
線上白板工具做得起來，但要補回兩件實體牆自帶的東西。第一是餘光：站在牆前的人看得見別人在哪一區猶豫，線上只看得到游標，主持人要主動點名。第二是移動：實體工作坊裡人會走過去撕下一張紙重貼，那個動作本身就是異議的表態，線上會變成沉默的拖曳。折衷做法是線上跑事件層，然後把熱點集中在一次實體或視訊的爭論時段，讓不同意的人真的開口。
把這面牆往前推一格、去問使用者為什麼走到這一步，可以接使用者故事地圖；如果爭議不在時間點而在「這一步歸誰做」，那要換的是泳道圖。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。