從重複發生的事件到改善待辦清單
示意性應用情境，並非案例研究。
將反覆發生的事件依可能原因分組，估算修復所需的工作量，並與反覆處理工單的成本比較，供負責人排定改善待辦清單中的修復優先順序。
問題
同樣的事件每個月都會回來：一個失敗的介面、一份在結帳期逾時的報表、一項每次發布後都會偏移的組態。每一個都被單獨解決，沒有人對這種模式負責，支援預算一次又一次地為同一個問題付費。
目前做法
症狀消失後，事件被逐一結案。月報依類別統計工單數。只有重大事件才做根本原因分析。改善需求與新專案需求競爭，很少被排入時程，於是重複發生的工作一直留在支援佇列中。
查看情境
快速概覽
示意性工作流程。含字幕。
逐字稿
- 同樣的事件每個月都會回來。每起事件都單獨處理，卻沒有人負責追蹤反覆出現的問題，支援預算一再為同一個問題買單。
- 已解決的事件依可能原因分組。對每個群組估算修復規模，並與重複發生所耗費的工單與工時比較。
- 負責人核准進入改善待辦清單的修復。變更經過發布檢查，事件資料顯示問題是否再度出現。
- 衡量指標：再發生率與花在重複發生事件上的支援工時。示意性應用情境。歡迎討論您的情境。
詳細情境
示意性情境。 一位虛構的支援工程師將每月重複發生的事件，轉化為由負責人排定優先順序並經過發布檢查的改善項目。 1:01
逐字稿
- Sam 還沒打開工單就認出了它。同樣的症狀又出現了，同樣的調查也再來一次。
- 個別來看，這些事件都已解決。合在一起看，它們似乎指向一個重複發生的問題，值得有人負責。
- 依可能原因將事件分組，驗證這個模式，並比較修復所需的工作量與重複發生所帶來的支援工作。
- 由負責人決定這項修復是否納入改善待辦清單，以及相對於其他優先事項的排序。
- 核准的變更要經過發布與回歸檢查。建議的改善並不等於獲准變更正式環境。
- 發布之後，追蹤問題是否再次出現，以及耗用了多少支援工作量。您的團隊接下來應該調查哪一個重複問題？
- [片尾] 您的團隊接下來應該調查哪一個重複問題？ 討論您重複發生的事件. qxorbit.ai/zh-hant/contact
- 示意性應用情境，並非案例研究。
建議的工作流程
- 運用事件分類體系、解決記錄和受影響元件，依可能的根本原因將已解決的事件分組
- 對每個重複發生的群組估算修復規模：所需變更、涉及的環境、發布與回歸工作量
- 將修復成本與重複發生的成本比較：每月工單數、工程師工時、負責人描述的業務影響
- 將排序後的候選項目呈交應用系統負責人，由其決定哪些進入改善待辦清單
- 透過附回歸檢查的發布流程交付已核准的修復，並在發布後監控再發生情況
人員保有掌控權的環節
- 分組和規模估算只是建議；由負責人決定修復什麼以及依什麼順序修復
- 計畫中的改善遵循協議的發布與回歸流程；緊急變更需要協議的緊急授權
- 在決定是否結案改善項目之前，對照協議的觀察期檢視再發生資料
平台對應僅表示可評估此構想的環境。實際導入取決於設定、授權、API、資料與權限。效益以定性方式描述；數值化的主張需有書面記錄的基準。