如何製作 SOP 流程圖
如何製作 SOP 流程圖：一張圖只畫一條程序，步驟編號，判斷點寫明判定準則，並有一個納入變更管理的已批准版本。附一個完整的事故管理示例。
SOP 流程圖就是把標準作業程序畫成流程：步驟有編號，能讓人在壓力下照著執行；判斷寫明準則；而且只有一個已批准的版本。
簡而言之
- 一張圖只畫一條程序。兩個起點即代表兩份 SOP。
- 步驟要編號，而且短到可以在壓力下讀出聲來。
- 每個判斷都寫明判定準則，或者指名由誰裁定。
- 升級路徑與重開路徑要畫出來，而不是心照不宣。
- 只有具備已批准版本、負責人和檢討日期，SOP 才算受控。
把流程圖連到受控程序
SOP 與一般流程圖的分別在哪裡
SOP 流程圖被閱讀的場景，和一般流程圖完全不同。流程圖是在會議上看的；SOP 是凌晨兩點由一個從未處理過這類情況的人開啟的，他只需要知道下一步該做什麼。這個分別決定了每一個設計選擇：步驟要短，要編號，以便在電話裡讀出來；判斷上要寫明準則；除非由指名的角色裁定，否則不留任何靠個人判斷的分支。
把範圍限定在一條程序上。SOP 流程圖最常見的缺陷，是三條程序擠在同一頁上，結果長到沒有人再願意開啟。如果你的圖有兩個起點，或者其中一段只適用於某一個團隊，就把它拆開。SOP 之間互相引用幾乎沒有成本；一份二十頁、沒有人讀的 SOP 才是真正的成本。
SOP 的另一半是控制。沒有批准紀錄、沒有版本號、沒有檢討日期的程序只是一份建議——在受規管的環境裡，一份沒有版本控制的 SOP 本身就是一項審核發現。下面的示例是一條事故管理程序，包含重大事故分支、SLA 違約升級路徑和重開的循環，並附有由同一批行生成的程序正文。
以流程圖呈現的 SOP
一條分四個階段建立的事故管理程序。下方帶編號的程序正文與圖表來自同一批行。
先記錄，再診斷
發現、記錄影響、分類並定優次。SOP 要由閱讀它的人真實身處的那一刻開始——對事故而言，那一刻是還沒有人知道哪裡出了問題的時候，所以記錄排在診斷之前。
在嚴重程度判斷處分支
「重大事故？」把程序一分為二：宣告重大事故、開設應變會議橋、通知持份者——或者繼續由一線作初步診斷。這個判斷的準則應該寫在判斷本身上，因為它是由當值的人在時間壓力下作出的。
按規則升級，而不是憑感覺
二線調查、一次明確的 SLA 檢查並附違約升級分支，然後恢復服務並與用戶確認。請留意重開路徑：用戶未確認的修復會退回診斷，而不是抱著僥倖心態結案。
結案，並把學到的東西回饋出去
填寫結案說明，然後判斷根本原因是否仍然不明——如果仍然不明，就建立一條問題紀錄。在「服務已恢復」就結束的 SOP，恰恰失去了那個能防止同一事故重演的產出。
運作方式
把範圍限定在一條程序上
用一句話寫出觸發條件：「發現或接獲報告的事故」。如果觸發條件需要一個「或」，而它涵蓋的是一種確實不同的情況，那就是第二份 SOP。讓每張圖只畫一條程序，才能讓它短到可以在緊急情況下被開啟。
把步驟寫成指令
動詞行先，一步一個動作，直接向執行的人說：「記錄事故及其影響」，而不是「事故被記錄」。被動語態會隱藏負責人，而步驟沒有負責人的 SOP，正是兩個人做同一步、第三個人一步都不做的原因。
把判定準則寫在判斷上
「重大事故？」旁邊需要一個定義——受影響用戶數目、服務級別、收入影響，視乎貴機構實際採用的口徑。用步驟的備註欄位寫這條規則。沒有準則的判斷，會被每一個讀圖的人以不同方式作出，而「標準」二字也就失去意義。
補上升級路徑與重開路徑
畫出 SLA 即將違約時會發生什麼、修復不奏效時會發生什麼、平時負責這件事的人不在時會發生什麼。人們查閱 SOP 正是為了這些路徑。每一條要麼匯回主流程，要麼以自己的終止點結束。
分配泳道，再與當值團隊一起走一遍
把每一步放進執行它的角色所屬的泳道——服務台、事故經理、二線——並和將來要用它的人一起通讀。問他們會在哪裡猶豫。每一次猶豫，都是一個欠缺判定準則或需要拆分的步驟。
批准它、為它建立版本，並設定檢討
把圖表送進審批流程，讓當前版本帶有審核人和日期，並加上檢討觸發條件：任何一次重大事故之後，以及至少每年一次。在 QueryChart 裡，批准紀錄與變更歷史與圖表放在一起，因此「三月份生效的是哪個版本」是有答案的。
應避免的錯誤
一份其實是三份的 SOP
兩個起點，或者其中一段只適用於某一個團隊，都說明這張圖應該拆開。篇幅正是令 SOP 在最要緊的一刻沒被開啟的原因。
沒有準則的個人判斷
「嚴重就升級」不是標準作業程序。寫下門檻，或者指名由誰裁定——只有這兩種方式能令判斷可重複。
沒有異常路徑
順利路徑是大家本來就知道的。一份略去 SLA 違約、重開和負責人不在的 SOP，恰恰在最需要它的地方保持沉默。
沒有版本控制
沒有已批准的版本和變更歷史，就沒有人能說明出事時哪條程序在生效——在受規管的環境裡，這本身就是一項審核發現。
製作你自己的 SOP 流程圖
把事故管理示例開啟為你自己的圖表，或者由空白開始，把你的程序寫進各行裡。
相關指南
常見問題
SOP 與流程圖有什麼分別？
SOP 是執行某項具體工作的受控指令：有編號、有負責人、經過批准、受版本控制，寫給真正動手的人看。流程圖是工作如何流動的圖示，通常橫跨多個角色，而且可能只屬描述性質，並不具強制力。把 SOP 畫成流程圖可以兼得兩者——圖表的可讀性加上程序的控制屬性——前提是批准紀錄與版本歷史一併跟上。
SOP 應該做成流程圖還是文字？
兩者都要，而且出自同一個來源。流程圖在壓力下更容易照著走，也令分支上的缺口顯現出來；文字則承載圖表容納不了的細節，例如精確的欄位數值或安全警示。真正的失敗模式是把它們當作兩份獨立文件來維護，因為它們會逐漸脫節。讓程序正文與圖表由同一批行生成，改動其中一處就等於兩處都改。
SOP 流程圖應該多長？
短到能以可讀的字級放進一個畫面——實際上大約十五至二十五個步驟。超過這個規模，就找一個自然的交接點，把它拆成兩條互相引用的程序。長的 SOP 並不更嚴謹，只是更不容易被開啟；而沒有人開啟的 SOP，提供的控制力和完全沒有 SOP 一樣多。
SOP 由誰批准？
流程負責人，加上為該程序所控制的風險問責的人——通常是品質、合規或該服務的負責人。就程序而言，關鍵在於批准紀錄掛在某個具體版本上，並帶有姓名和日期，這樣過去任何一個時間點上哪份文本生效都不會含糊。正是這條紀錄，把一份文件變成受控文件。
