如何建立流程圖
如何建立流程圖：確定觸發事件與結束狀態，每個方框只寫一個動作，把每一個「如果」變成帶標籤的決策，並讓每條分支都有歸宿。附一個可逐步檢視的完整示例。
流程圖呈現工作實際發生的次序：一個觸發事件、每個方框一個動作、每處分叉都有一個帶標籤的決策，以及每條分支上明確的結束狀態。
簡而言之
- 先確定觸發事件和終點線；其餘都是中間部分。
- 每個方框一個動作，用動詞開頭：「在應付帳款系統中登記發票」，而不是「發票處理」。
- 每個決策都是一個問題，由它引出的每條出口都帶標籤。
- 每條分支要麼匯回流程，要麼以自己的終止符結束——不容許有懸在半空的線。
- 異常路徑才是令這張圖值回工夫的部分。
是什麼令流程圖成為流程圖
多數人第一次畫出來的流程圖，其實算不上流程圖。那只是一排用箭嘴連起來的矩形，描述的是一切都沒出錯的那個版本。這樣的圖不過是一份多加了幾個步驟的檢查表，這也正是為什麼那麼多流程圖畫完一次、列印出來，就再也沒人看——順利路徑本來大家就都知道。價值在於這張圖對其他所有路徑說了些什麼。
一張能用的流程圖，語法很小但很嚴格。只有一個開始。每個方框一個動作，用動詞開頭來寫，好讓誰做什麼一目了然。決策畫成一個問題，每條出口都帶標籤，讀的人才能看出自己該走哪一條。而每條分支要麼匯回主流程，要麼以自己的終止符結束——因為一條懸在半空的線，意味著沒有人知道接下來會發生什麼，而這正正是這張圖本該解決的情況。
下面的示例是一個真實的發票審批流程，分五個階段逐步搭建。留意每個階段發生了什麼：這張圖正是在異常出現時才真正變得有用——重複的發票、與採購訂單對不上的價格、退回供應商查詢後又從上游重新匯入流程的那條路。這三條分支，就是這張圖比檢查表更有價值的全部理由。
看一張流程圖是怎樣搭起來的
一個真實發票審批流程的五個階段。逐步檢視——每一步都會補上流程圖語法的下一塊。
一個觸發事件，一個起始步驟
任何流程圖都只以一個開始圖形起步，而且它命名的是一個事件而不是一項活動：發票送達，而不是「發票處理」。如果你的圖有兩個開始，那你畫的其實是兩個流程。
提出第一個問題
菱形是一個問題——「重複發票？」——兩條出口都帶標籤。留意「是」這條分支並沒有中途消失：它以自己的終止符結束，因為攔下一張重複發票是這個流程的一種正當結束，而不是圖沒畫完。
只拆分真正不同的路徑
有採購訂單的發票要與採購訂單和收貨單做三方對數；沒有採購訂單的發票則改為按成本中心入帳。分成兩條分支，是因為工作確實不同——而不是因為有人希望這張圖看起來更周全。
把異常送回流程裡
價格不一致會向供應商發起一次查詢，問題解決之後，流程由採購訂單核對處重新匯入，而不是由頭開始。回到流程中段的迴路很正常；不正常的是一條悄悄消失的異常分支。
以狀態收尾，而不是以活動收尾
審批按金額分流，超過限額需要會簽，圖最終停在「已向供應商付款並已發出付款通知書」——一個可以核實的狀態。「處理付款」是一項活動，而活動永遠不是終點線。
運作方式
先寫下觸發事件和終點線
在畫任何方框之前：什麼事件啟動這個流程，什麼狀態代表它已經結束？這兩句話確定了範圍，而關於流程圖的多數爭論，最後都會發現爭的是邊界而不是步驟。終點線要寫成一個狀態——「供應商已收到付款」——而不是一項活動。
先把步驟列成行，而不是畫成圖
在 QueryChart 中新建一張圖表，把步驟逐行填進 Box text 欄，一行一個。忍住不要去排版。列表比圖更容易拿來討論，而版面是自動生成的——連線交由應用完成，所以你在這裡手動擺放的東西反正也留不下來。
用行號把各行連起來
Line to 欄填的是下一個步驟的行號，所以第 2 行指向 3，箭嘴就畫出來了。某個步驟通向不止一個去處時，用逗號分隔填寫多個行號。在 QueryChart 中連接流程圖就只有這些內容，這也是為什麼從未用過繪圖工具的人也能修改這張圖。
把筆記裡的每一個「如果」變成決策
凡是筆記裡出現「如果」「除非」或「視乎情況而定」的地方，就把那一行的 Shape 設為 Decision，並把標籤改寫成一個問題。然後把答案填進 Line text 欄——「是」「否」「超過 10 萬港元」——讓每條出口都說明自己對應哪一種情況。沒有標籤的分叉，是流程圖讀不下去的最常見原因。
畫出異常路徑
取每個決策的不順利分支，把它一路跟到一個真實的結論：它是回到前面的某一步、移交給別人，還是就此終止？終止時給它一個終止符圖形。這是大家會略過的部分，也正是讀者真正需要的部分——沒有人會去翻流程圖，只為弄清楚一切順利時會發生什麼。
和實際做這項工作的人一起走一遍
把圖唸給實際執行這個流程的人聽，問他們哪裡不對。要預料到會發現：某一個步驟其實是三個，以及某一條從來沒有人寫下來的分支。在行裡改好，把圖表分享出去，並為它加上審批，讓大家看到的版本是達成共識的那一版，而不是別人簡報裡的一張截圖。
應避免的錯誤
把決策寫成陳述句
「主管審批」是一個步驟；「主管是否批准？」才是一個決策。菱形如果讀起來不像一個問題，由它引出的兩條線就沒法寫出像樣的標籤，讀的人只能猜哪一條適用於自己。
懸在半空的分支
每條線都必須落到某處：另一個步驟，或者一個終止符。一條就這樣斷掉的分支，是這張圖在承認沒有人知道那種情況下會發生什麼——這值得知道，但應當去解決，而不是照原樣畫出來。
一個方框做三件事
「審閱並批准並存檔」是三個方框，中間藏著兩個可能出錯的位置。如果一個步驟的標籤需要用「並」，它通常就不止一個步驟，而你看不見的那次交接，正是等候時間藏身的地方。
畫出自己希望擁有的那個流程
先把現狀流程畫出來，連異常和變通做法一併畫上，即使難堪。在還沒有人對今天究竟發生什麼達成共識之前就畫出來的目標流程圖，是一份建議書，也應當標明它是建議書。
建立你自己的流程圖
由上面的發票審批示例開始，或者把它清空，把你自己的步驟填進各行。
相關指南
常見問題
畫流程圖需要哪些圖形？
四種幾乎就承載了一切：終止符用於開始和每一種結束狀態，矩形代表一個動作，菱形代表一個決策，文件圖形代表會產生紀錄的步驟——一張簽署的表格、一份報告、一條寫入日誌的紀錄。QueryChart 另外提供 Reject 與 Success 兩種終止符，這很實用，因為一張圖通常不止一種結束方式，用不同顏色區分能令不順利的結局一眼可見。
流程圖應該畫到多細？
細到讓一個不做這份工作的人也能照著走下來，不必更細。一個實用的判斷：如果某個步驟可以交給另一個團隊而無需額外解釋，那它就是一個方框。如果解釋它要用上一整段，那它多半是一個子流程，值得有自己的圖並由這張圖連結過去。十五至二十五個方框，是多數營運流程仍能在一個畫面內讀完的區間。
流程圖和流程地圖有什麼分別？
流程圖呈現次序和邏輯：發生什麼、按什麼次序、經過哪些決策。流程地圖在這個次序之外補上背景——每個步驟歸誰負責、在哪個系統裡完成、輸入什麼、輸出什麼。實際上兩者的分別主要體現在泳道上：當你按負責人把流程拆開的那一刻，你手上的就是一張流程地圖，而對於任何跨越團隊邊界的事情，通常正是這個版本才值得擁有。
決策一定要是「是」或「否」嗎？
不一定，但它們必須窮盡且互斥。按變更類型分成三條——標準、常規、緊急——完全可以，只要每一個申請都恰好落入其中一類。真正會毀掉一張圖的，是某個決策帶標籤的出口沒有涵蓋所有情況，因為那位情況被遺漏的讀者無處可去，只會自己發明一條路。