如何建立工作流程圖
如何建立工作流程圖：把申請、審批關卡、實際工作以及那個令流程閉環的覆核畫出來，並讓每個狀態都有一個角色負責。附一個即時的存取權限申請示例。
工作流程圖展示一個工作事項如何在角色之間流轉：甚麼觸發它、它必須通過哪些審批、由誰執行，以及最終停在甚麼狀態。
簡而言之
- 單位是事項——一份申請、一張工單、一份文件——以及它經過的那些狀態。
- 每個關卡都要點名一位審批人，並寫清兩種結果。
- 一個事項絕不能停在沒有人盯着的狀態。
- 拒絕要有明確去向：打回修改，或進入一個已關閉的狀態。
- 如果存在周期性覆核，就把它畫出來——不少工作流會按時間重新開啟。
工作流程圖能顯示、而流程圖顯示不了的東西
工作流（workflow）與流程（process）這兩個詞經常混用，多數時候也無傷大雅。這個區分真正派上用場的時刻，是你要決定畫甚麼：流程圖描述工作是怎樣做的，而工作流程圖描述某一個具體事項——一份申請、一張工單、一份文件——如何在必須對它採取行動的人之間流轉。分析單位是這個事項以及它經過的狀態，而不是活動本身。
這會改變版面上應該出現甚麼。工作流程圖靠它的關卡而存在：誰必須審批、按甚麼次序，以及其中有人說「不」時會發生甚麼。任何一刻，一個事項可以停在哪裡、由誰持有，都必須毫不含糊——因為最常見的工作流故障不是一個錯誤的決定，而是一個事項停在了沒有人盯着的狀態。
下面的示例是一份存取權限申請。它有四個不同的審批人、一個可能把事項打回上一步的衝突檢查，以及一個在流程看似完結數月之後又把它重新開啟的重新認證循環——這很好地提醒我們：一個工作流的最後一個狀態，往往不是它的最後一個事件。
一個帶四道關卡的工作流
一份存取權限申請如何由表單走到已開通的權限——並在重新認證時再走出去。
觸發與第一道關卡
一份寫明理由的申請，隨後是直屬主管的決定。留意，理由是在任何審批之前就收集好的：一道關卡的質素，不會高於審批人所看到的資料。
順序而非並行的審批
系統負責人覆核權限範圍，職責分離檢查可以把事項退回去修改並重新檢查，而特權存取還會額外疊加一道保安審批。每一道關卡都有唯一的負責人，並為拒絕標註了明確的去向。
工作本身
按最小權限開通、向申請人確認、取得使用規範的知悉確認，並把該權限登記進權限登記冊。在多數工作流程圖裡，真正「做事」的那一段是最短的——而這通常正是那個發現。
把它重新開啟的那個循環
重新認證按固定節奏令工作流由頭再走一遍，而「是否仍然需要？」的答案要麼再次確認這項權限，要麼觸發回收。一個只向前走的工作流，會令權限日積月累地堆上好幾年。
運作方式
為事項及其狀態命名
寫下流轉的到底是甚麼——一份申請、一張發票、一份文件——以及它可能處於的狀態：已提交、已批准、已開通、已回收。當讀者問「這件事現在到了哪裡」，他們要找的就是狀態，所以先把狀態談定，能避免圖表變成一份工作清單。
按生效次序列出各道關卡
對每一次審批，記下由誰負責、他們在決定甚麼。然後檢查這個次序是不是真實的：本來可以並行的關卡，經常被畫成順序，只因為工單系統當初就是那樣設定的——這一點值得攤開來講，而不是就此固化下來。
把狀態寫成列並連接起來
把每個狀態或動作放進一列，把關卡的「Shape」設為 Decision，再用「Line to」欄把它們連接起來。每道關卡的兩個出口都要在「Line text」裡標註文字。做到這一步，圖表就已經能替你指出任何一個出不去的狀態。
為每個狀態指定一條泳道
把每一列放進那個在該狀態下持有事項的角色的泳道。正是這一步，令這張圖成為「我的申請現在壓在誰手上」的答案——而那是工作流程圖被問得最多的一個問題。
為拒絕規劃去向
一個被拒絕的事項總要去某個地方：退回給申請人修改、進入一個已關閉的狀態，或轉交例外處理的負責人。把它畫出來。讓拒絕停留在言外之意的工作流，恰恰會製造出那種典型故障：事項既不在辦、也未關閉，而且沒有人去催。
加上周期性覆核
如果這個事項會按計劃被重新審視——權限重新認證、文件定期覆核、合約續期——就把它畫成一條回到工作流的路徑，並帶上自己的決策點。否則這張圖就暗示工作到此為止，而登記冊會悄悄堆滿沒有人再看一眼的紀錄。
應避免的錯誤
沒有負責人的狀態
不屬於任何泳道的「待審核」，意味着沒有人對推動它負責。每個狀態都屬於某個人，即使那是一個有指定負責人的佇列。
畫的是工具而不是工作
照抄工單系統的狀態清單，得到的是一張關於設定的圖。先問真正必須發生甚麼，再拿來對照——差異之處才是有意思的部分。
為求安心而層層疊加的審批
每多一道關卡都會拉長周期時間並稀釋問責，因為五分之一的審批人簽得很快。兩道有意義的關卡勝過五道禮節性的。
拒絕沒有出口
如果圖表沒有說明審批人說「不」之後會發生甚麼，那麼這個工作流最常見的非理想結局就是未有定義的。
建立您自己的工作流程圖
把存取權限申請示例作為您自己的圖表開啟，把關卡、審批人與狀態替換成你們自己的。
相關指南
常見問題
工作流程圖和業務流程圖有甚麼分別？
業務流程圖描述工作是怎樣執行的；工作流程圖描述某一個具體事項如何在對它採取行動的人之間流轉，重點在狀態、歸屬與審批關卡。在實務上兩者大量重疊，同一套圖形符號也能同時服務兩者。這個區分更有用的地方是當成一道自我檢查：如果你說不出流轉的是甚麼事項、它可能處於哪些狀態，那你畫的是流程圖，而不是工作流。
一個工作流應該有多少個審批環節？
只保留承載真實決策的那些。每道關卡都會增加排隊時間，超過兩三道之後還會稀釋問責——五分之一的審批人往往看都不看就簽了，這比沒有關卡更糟，因為它製造出一份「覆核發生過」的證據，而覆核並未發生。如果一道關卡從來沒有拒絕過任何東西，它就是一則通知，也應該按通知來畫。
工作流程圖需要用泳道嗎？
幾乎總是需要。工作流程圖被問得最多的問題，是這個事項現在由誰持有，而泳道不需要任何人去讀方框裡的文字就能回答它。例外是那種從不離開一個團隊的工作流——在那裡泳道只會多出一個不承載資訊的維度。
按計劃重複發生的工作流怎樣表示？
把觸發點畫成一個步驟，並用一個關於結果的決策把它接回流程中。在存取權限示例裡，重新認證是一個計劃內的步驟，接入「權限是否仍然需要？」的決策，結果要麼再次確認、要麼回收。把這一點顯式建模出來，正是令工作流程圖不再暗示「事項一旦辦完就永遠完結」的關鍵。
