如何繪製一條業務流程
如何端到端繪製一條業務流程：先議定界線，訪談真正執行工作的人，把包含例外在內的現狀畫出來，然後逐一驗證。附一個可即時操作的採購到付款示例。
繪製業務流程，就是就它由哪裏開始、到哪裏結束達成共識，弄清這兩點之間實際發生了甚麼，並把它記錄成一張執行工作的人願意認可的圖。
簡而言之
- 把範圍表述成兩個事件——一個觸發條件和一個終止狀態——而不是一個主題範疇。
- 訪談真正執行工作的人，並專門追問例外情況。
- 先畫現狀。在沒有人對「今天是怎樣」達成共識之前畫出的未來流程，只是一份建議。
- 把外部持份者放進各自的泳道：等待供應商的時間同樣算在你們的周期時間裏。
- 驗證的方式是與每一位泳道負責人逐步走一遍，然後只保留一個已批准的版本。
在你動筆之前就已經出錯的事
流程繪製在任何人動筆之前就已經出錯了。當範圍被表述成一個題目——「梳理採購」——而不是兩個事件時，它就錯了：每一次訪談都會帶出另一條流程，圖不斷變大，直到它描述的是整間公司。先把界線釘死：這條流程由開出請購單開始，到供應商收到貨款結束。這兩個事件以外的一切，都是別人的圖。
第二類失敗出在取材上。依據書面政策畫出來的圖，記錄的是應該發生甚麼；依據系統畫出來的圖，記錄的是系統容許甚麼。兩者都不是流程本身。流程要由真正在跑它的人那裏取得，尤其是要問他們：正常路徑走不通時，你們會怎樣做。變通做法不是雜訊，它就是流程，而風險通常正落在那裏。
以下示例是一條跨五條泳道（包括供應商）的採購到付款流程。逐步走一遍，看看一張完整的圖在順利路徑之外還包含甚麼：阻止資金被提早佔用的關卡、工作離開公司的那個節點，以及採購訂單、收貨紀錄與發票三者對不上時形成的例外隊列。
一條端到端繪製出來的業務流程
跨五條泳道的採購到付款流程，分五個階段搭建——先是界線，然後是控制關卡，最後是例外。
釘死界線
圖由「識別採購需求」開始，並會在付款處結束。兩個事件，先於其他一切寫下來——因為「供應商甄選算不算這條流程的一部分」這場爭論，現在吵要便宜得多。
找出控制關卡
主管批准、預算可用性，隨後是一道按金額把事項轉交財務總監的門檻。控制關卡正是業務流程圖最常被用來揭示的東西，而那道金額門檻的判斷，能看出授權矩陣與實際做法是否一致。
標出工作離開公司的位置
尋源轉入採購部門，再轉入供應商自己的泳道。交付步驟分成兩條各自獨立推進的支線——貨品進來、發票進來——這是這條流程真實存在的特徵，在一份線性清單裏根本看不見。
畫出例外，而不只是順利路徑
三方核對是發票去送命的地方。不相符的分支退回採購部門，改正之後重新進入核對：一張誠實的圖會把這個迴路畫出來，因為周期時間實際上就花在這個迴路裏。
在你承諾過的那個事件上結束
「付款已放行予供應商」——正是第一階段命名的那個終止狀態。一張停在自己聲明的界線以外的圖，是一張在繪製過程中範圍已經漂移的圖。
運作方式
把範圍寫成兩個事件
「由開出請購單開始；到供應商收到貨款結束。」一句話，在任何訪談之前，與提出繪圖需求的人達成共識。如果大家對界線有分歧，這個分歧就是第一個發現，而且現在解決比畫完三版之後再解決便宜得多。
確定泳道以及泳道裏的人
列出工作會經過的角色，包括外部持份者，並為每條泳道找到一位真正在執行這些步驟的人，而不是一位在管這些步驟的人。四至五條泳道；如果你需要八條，說明範圍太闊，應當在一次交接處拆開。
訪談要衝着例外去，而不是衝着常規
順利路徑人人都能講，而問題很少出在那裏。要問的是：預算科目缺失時你們怎麼辦？審批人放假時怎麼辦？發票早於貨品到達時怎麼辦？這些答案就是那些分支，而且它們幾乎從不寫在別的任何地方。
用列搭出現狀，泳道留到最後
把步驟輸入 QueryChart 成為一列列內容，用「連線至」欄把它們連起來，然後為每一列指派一條負責人泳道和一個階段。在操心版面之前先把次序理對，能令討論一直停在流程上；圖表會自行由這些列組裝出來。
量度交接
對每一次跨泳道的流轉，記下下一條泳道是怎樣知道自己有工作的，以及它通常要等多久。寫進這個步驟的備註裏。大多數業務流程的周期時間是排隊時間而不是作業時間，而隊列恰好就排在這些界線上。
驗證、批准，並只保留一個版本
與每一位泳道負責人逐步走一遍完成的圖，把他們不認可的地方改掉。然後在 QueryChart 裏讓它走完審批，這樣就有一個帶簽署和日期的現行版本，而不是一份在工作坊結束翌日就開始與現實脫節的 PDF。
應避免的錯誤
把範圍表述成一個題目
「梳理採購」沒有界線，於是每一次訪談都會在兩端各加一個步驟。兩個事件，寫下來，達成共識。其餘的都可以商量，這一條不可以。
照着政策文件畫
政策是某個人的意圖。圖要記錄的是實際發生了甚麼。兩者不一致的地方，那道落差正是整個練習最有用的產出——所以不要靠把政策畫出來，悄無聲息地把它抹平。
把外部持份者留在圖外
如果流程要等供應商或客戶，他們就該佔一條泳道。否則這張圖會暗示延誤發生在內部，改善的力氣也就用錯了地方。
一張圖，用到永遠
流程會變。沒有負責人、沒有覆核日期的圖，是一間已經不存在的公司的快照。給它一位負責人、一個固定的覆核周期和版本控制，令現行版本可以被辨認出來。
繪製你們自己的業務流程
由採購到付款示例開始，或者開啟一張空白圖表，把你們的步驟輸入到列裏。
相關指南
常見問題
流程繪製與流程建模有甚麼分別？
流程繪製產出的是一張人們真的會拿來用的圖：誰做甚麼、按甚麼次序、有哪些判斷和交接。流程建模產出的是一份形式化、受符號規範約束的表述——通常是 BPMN——工具可以對它作校驗或直接執行，它對事件類型、閘道和訊息流都有規則。大多數機構需要的是那張圖。只有當下游確實有東西要消費它時，例如一個工作流程引擎或一個自動化項目，才去動模型。
我應該畫現在的流程還是改善後的流程？
畫現在的，而且永遠先畫現在的。現狀圖是一份可以與執行工作的人一起驗證的事實紀錄，這令它成為一項共識而不是一種看法。有了它之後，未來流程圖不過是一次簡短又便宜的對話，談的是幾處具體改動。跳過現狀，就等於改善是針對一條假想的流程去設計的，而這個假想通常就是順利路徑。
繪製一條業務流程應該花多長時間？
對一條有四至五條泳道的單一營運流程來說：幾個小時的訪談、一個下午起草，再加一場驗證會。折合兩至三天的投入，分散在日曆上。凡是要花上幾個星期的，通常是範圍問題而不是複雜度問題——界線沒有釘死，於是圖不斷向旁邊的鄰接流程蔓延。
業務流程圖應該由誰負責？
一位可以修改它的具名人員，通常是流程負責人，而不是主持這次繪製的那個人。泳道負責人負責覆核；流程負責人負責維護。沒有唯一負責人，圖會以一種可預見的方式失效：它在技術上一直可用，卻悄無聲息地不再對得上現實，這比根本沒有圖更糟，因為大家仍然相信它。
