在事件風暴上，實現下面幾個步驟：
- 我們首先進行了一次混沌探索，從每個人那裡收集了相關的領域事件。
- 之後，我們透過整理事件、刪除重複事件和微調事件來組織混亂。
- 會議結束時，我們將事件按時間順序排列。
- 我們還指出了一個熱點，強調了我們不確定的事情。
- 此外，我們還使用了一些黃色便籤來記錄我們不想忘記的關鍵部分。
- 另外，我們還指出了主裝置清單流程中的初始子流程。我們突出了這些子流程，並給它們起了臨時名稱。
這裡是我們完成後的 Miro 板快照。
看上去好像非常清晰。
但是，即使一切都井然有序，來龍去脈看起來也很清晰，我們還是意識到在先前的建模中可能還隱藏著一些漏洞或不一致的地方。
幸運的是，"大局事件風暴 "提供了兩種技術：
- 顯式演練（explicit walk-through）
- 反向敘述（reverse narrative）
可以幫助我們找出這些漏洞或不一致之處。
對於利益相關者來說，認識到我們不知道的事情往往是有價值的知識，尤其是當他們以前不知道的時候。
讓我們從理論入手，瞭解如何找到事件流程中的漏洞。
1、顯式演練walk-through
顯式演練技術是 "事件風暴 "工作坊的一種方法，用於檢查模型是否準確和完整。
它包括：
- 對研討會期間制定的整個事件序列進行詳細審查。
- 它可以讓參與其中的每個人一起檢查流程的每個部分。
這樣，我們就能發現不一致之處、不必要的部分或任何遺漏。它確保我們所有人都瞭解業務流程。
在此過程中：
- 主持人可能會要求某個人按照事件的時間順序開始講述故事。
- 這個講故事的角色可以傳來傳去，讓每個人都參與進來。
為了有效地驗證流程步驟並找出潛在的差距或不一致之處，在事件流程中提出正確的問題至關重要。
雖然通常是由主持人開始提問，但參與者通常也會發現其價值並開始提問。
常見的、有用的問題有助於發現潛在的缺失要素，這些問題包括：
- 為什麼會發生這一事件？
- 該事件的發生還有其他原因嗎？
- 該事件如何影響系統狀態？
- 在此事件和之前的事件之間會發生什麼？
- 此事件之後發生了什麼？
- 該事件對業務有何影響？
- 該事件可能不會發生嗎？如果有，這種情況的後果是什麼？
- 如果該事件不止一次發生怎麼辦？
- 該事件是否存在特殊情況？
- 能否將此事件拆分為更小、更具體的事件？
這些問題可以幫助我們找到最初可能忽略的事件，確認每個事件的重要性，並探究事件發生前後的情況。這些問題還能幫助我們瞭解事情是否有可能以不同的方式發展。
這些問題很多，只是舉例說明。我們不需要在每次事件中都提出所有問題，那樣就太多了。經驗豐富的主持人和建模者知道哪些問題對不同的事件有意義。
這種方法最重要的一點是，我們要根據事件發生的順序來審查事件，而這一順序是在最初的頭腦風暴階段確定的。它不同於我們用來檢查工作的另一種方法，即逆向敘述法（reverse narrative）。
2、逆向敘述
我們經常使用的另一種發現流程中潛在漏洞的方法叫做反向敘述。與明確的 "走一遍walk-through "不同，我們從流程的末端開始，也就是時間軸上的最後一個事件。這種方法提供了一個獨特的視角，可以發現隱藏的假設、遺漏的步驟或流程中比實際需要更復雜的部分。
透過從預期結果出發，詢問 "我們是如何到達這裡的？"，鼓勵參與者批判性地思考之前發生的事情。回過頭來看事情，我們會重新考慮每個事件是否真的有必要，或者是否可以簡化。
就像在顯式演練walk-through中一樣，我們會提出一些問題來檢查每個事件是否合理，並找出我們可能遺漏的問題。我前面提到的問題在這裡也適用，但我們要對它們稍作調整，以適應逆向視角。例如
- 這個事件發生的前提是什麼？
- 如何以不同的方式實現這一結果？
- 這一事件發生的必要條件是什麼？
- 怎樣才能避免這一事件的發生？
逆向思維不是我們通常的做事方式。想想看，從 A 到 Z 還是從 Z 到 A，哪個感覺更自然、更容易？這種逆向思維可以幫助我們注意到我們第一次錯過的東西。
反向敘述技術或類似的逆向分析方法通常被執法和調查機構（如警方）用於開展刑事調查和分析事件。它尤其適用於捕捉嫌疑人故事中的不一致之處。在 "事件風暴法 "中，我們的目標不是抓住任何人的謊言，而是確保他們所描述的過程是完整的，並且不依賴於不言而喻的假設。
這兩種技術的主要優點都是確保建模流程的完整性和事件的正確表達。不過，這兩種技術還能幫助所有相關人員對流程達成共識。它不僅能確保各團隊共享領域知識，還能確保這些知識得到驗證。這有助於縮小技術和非技術參與者之間的差距，使所有人都能訪問和理解複雜的領域邏輯。它還支援建立用於表達領域模型的通用語言。
既然我們已經介紹了理論知識，那就讓我們看看在我們的課程中是如何實現的。
尋找流程中的漏洞
在研討會上，我們選擇了反向敘述技術。為什麼呢？因為我們（建模者）只是對我們正在使用的流程略知一二，因為我們只是它的使用者。但是，我們的專家對許多隱藏的方面瞭如指掌，而我們卻不瞭解。
鑑於參與者對流程的瞭解程度存在差異，逆向技術有助於我們更嚴格地檢查流程。根據我的經驗，當每個人對流程的理解都差不多時，明確的演示會更有效。這種情況非常罕見，所以我們通常會採用反向敘述法。
反向流程
從流程的末端開始，我們很快意識到，裝置退役的原因與我們最初的想法不同。
在上一環節中，我們瞭解到裝置退役的原因有兩種，一種是裝置已完全損壞且無法修復，另一種是在更換裝置後選擇退役。
雖然這兩種情況一般都是正確的，但我們意識到事件發生的順序並不正確。具體來說，當服務部門宣佈裝置無法使用時，第一步實際上是啟動因損壞而更換的程式。在該子流程之後，將觸發退役流程。
有趣的是，在使用反向敘述時，我們發現了一個審查裝置庫存的迴圈流程。這凸顯了使用這種技術的一個重要原因--它可以幫助我們發現我們遺漏的子流程、事件，或者一開始並不清楚、也沒有被識別出來的不同做事方式。
在這個被發現的審查子流程中，每個裝置都可能被庫存、出售或退役（如果認為太舊無法再利用）。因此，在這種情況下也可以啟動退役流程。
除了我前面提到的改變流程的起點之外，我們還意識到流程本身的功能與我們最初想象的有些不同。具體來說，一旦做出決定，證明裝置已退役的文件也會被髮送到外部會計系統。
此外，我們將最初事件的措辭從 "裝置已退役 "改為 "已決定退役裝置"，以更準確地反映事件的含義。此時，裝置並未實際退役。我們只是決定這樣做。
裝置更換流程
反向敘述幫助我們更好地理解流程的另一個例子是裝置更換。起初，我們認為這是一個簡單明瞭的過程，但在第一次會議結束時，情況卻變成了複雜：
在這一階段，只有一種方法可以啟動該流程，即當承包商申請更換裝置時。這將觸發發放裝置的常規流程，與新承包商的情況類似。然後，"舊 "電腦可能會根據其狀況歸還庫存或退役，但前提是承包商必須清除裝置資料。
然而，當我們回過頭來看這些事件，並提出正確的問題時，發現情況更為複雜。
首先，我們發現了啟動這一過程的其他方法。這不僅僅是承包商因為舊裝置過時而要求更換新裝置的問題。例如，承包商可能會丟失裝置、意外損壞甚至被盜。此外，假設服務部門確定電腦無法維修。在這種情況下，這也是啟動更換流程的訊號，我在討論退役流程的更新時對此進行了描述。
在所有這些情況下，都需要一臺新裝置，從而觸發主裝置釋出流程。如果只是更換，承包商可以選擇購買裝置。這就啟動了出售公司裝置的流程。否則，裝置將返回庫存池，供其他承包商使用或退役。
在裝置丟失、被盜或損壞的情況下，退役流程也會啟動。此外，無論在哪種情況下，我們都需要將裝置的任務從承包商處刪除。我們還探討了裝置丟失或被盜時應採取的其他措施。不過，由於我們（幸運地）從未遇到過此類事件，因此我們決定推遲討論。因此，我們在與這些情況相關的事件中新增了兩個熱點。
正如您所看到的，我們對這一流程進行了重大修改。我們發現了具有各種流程的不同場景，並發現了之前沒有發現的事件。這顯示了逆向敘述技術的威力。
（banq注：並不是逆向敘述技術的威力，而是人的認知透過反覆琢磨思考的深入，切莫歸因於教條，把自己變成宗教教徒）