如何製作 SOP 流程圖
如何製作 SOP 流程圖：一張圖只畫一條程序，步驟編號，判斷點寫明判定準則，並有一個納入變更管理的已批准版本。附一個完整的事故管理示例。
運作方式
把範圍限定在一條程序上
用一句話寫出觸發條件：「發現或接獲報告的事故」。如果觸發條件需要一個「或」，而它涵蓋的是一種確實不同的情況，那就是第二份 SOP。讓每張圖只畫一條程序，才能讓它短到可以在緊急情況下被開啟。
把步驟寫成指令
動詞行先，一步一個動作，直接向執行的人說：「記錄事故及其影響」，而不是「事故被記錄」。被動語態會隱藏負責人，而步驟沒有負責人的 SOP，正是兩個人做同一步、第三個人一步都不做的原因。
把判定準則寫在判斷上
「重大事故？」旁邊需要一個定義——受影響用戶數目、服務級別、收入影響，視乎貴機構實際採用的口徑。用步驟的備註欄位寫這條規則。沒有準則的判斷，會被每一個讀圖的人以不同方式作出，而「標準」二字也就失去意義。
補上升級路徑與重開路徑
畫出 SLA 即將違約時會發生什麼、修復不奏效時會發生什麼、平時負責這件事的人不在時會發生什麼。人們查閱 SOP 正是為了這些路徑。每一條要麼匯回主流程，要麼以自己的終止點結束。
分配泳道，再與當值團隊一起走一遍
把每一步放進執行它的角色所屬的泳道——服務台、事故經理、二線——並和將來要用它的人一起通讀。問他們會在哪裡猶豫。每一次猶豫，都是一個欠缺判定準則或需要拆分的步驟。
批准它、為它建立版本，並設定檢討
把圖表送進審批流程，讓當前版本帶有審核人和日期，並加上檢討觸發條件：任何一次重大事故之後，以及至少每年一次。在 QueryChart 裡，批准紀錄與變更歷史與圖表放在一起，因此「三月份生效的是哪個版本」是有答案的。
常見問題
SOP 與流程圖有什麼分別？
SOP 是執行某項具體工作的受控指令：有編號、有負責人、經過批准、受版本控制，寫給真正動手的人看。流程圖是工作如何流動的圖示，通常橫跨多個角色，而且可能只屬描述性質，並不具強制力。把 SOP 畫成流程圖可以兼得兩者——圖表的可讀性加上程序的控制屬性——前提是批准紀錄與版本歷史一併跟上。
SOP 應該做成流程圖還是文字？
兩者都要，而且出自同一個來源。流程圖在壓力下更容易照著走，也令分支上的缺口顯現出來；文字則承載圖表容納不了的細節，例如精確的欄位數值或安全警示。真正的失敗模式是把它們當作兩份獨立文件來維護，因為它們會逐漸脫節。讓程序正文與圖表由同一批行生成，改動其中一處就等於兩處都改。
SOP 流程圖應該多長？
短到能以可讀的字級放進一個畫面——實際上大約十五至二十五個步驟。超過這個規模，就找一個自然的交接點，把它拆成兩條互相引用的程序。長的 SOP 並不更嚴謹，只是更不容易被開啟；而沒有人開啟的 SOP，提供的控制力和完全沒有 SOP 一樣多。
SOP 由誰批准？
流程負責人，加上為該程序所控制的風險問責的人——通常是品質、合規或該服務的負責人。就程序而言，關鍵在於批准紀錄掛在某個具體版本上，並帶有姓名和日期，這樣過去任何一個時間點上哪份文本生效都不會含糊。正是這條紀錄，把一份文件變成受控文件。