如何繪製一條業務流程
如何端到端繪製一條業務流程：先議定界線，訪談真正執行工作的人，把包含例外在內的現狀畫出來，然後逐一驗證。附一個可即時操作的採購到付款示例。
運作方式
把範圍寫成兩個事件
「由開出請購單開始；到供應商收到貨款結束。」一句話，在任何訪談之前，與提出繪圖需求的人達成共識。如果大家對界線有分歧，這個分歧就是第一個發現，而且現在解決比畫完三版之後再解決便宜得多。
確定泳道以及泳道裏的人
列出工作會經過的角色，包括外部持份者，並為每條泳道找到一位真正在執行這些步驟的人，而不是一位在管這些步驟的人。四至五條泳道；如果你需要八條，說明範圍太闊，應當在一次交接處拆開。
訪談要衝着例外去，而不是衝着常規
順利路徑人人都能講，而問題很少出在那裏。要問的是：預算科目缺失時你們怎麼辦？審批人放假時怎麼辦？發票早於貨品到達時怎麼辦？這些答案就是那些分支，而且它們幾乎從不寫在別的任何地方。
用列搭出現狀，泳道留到最後
把步驟輸入 QueryChart 成為一列列內容，用「連線至」欄把它們連起來，然後為每一列指派一條負責人泳道和一個階段。在操心版面之前先把次序理對，能令討論一直停在流程上；圖表會自行由這些列組裝出來。
量度交接
對每一次跨泳道的流轉，記下下一條泳道是怎樣知道自己有工作的，以及它通常要等多久。寫進這個步驟的備註裏。大多數業務流程的周期時間是排隊時間而不是作業時間，而隊列恰好就排在這些界線上。
驗證、批准，並只保留一個版本
與每一位泳道負責人逐步走一遍完成的圖，把他們不認可的地方改掉。然後在 QueryChart 裏讓它走完審批，這樣就有一個帶簽署和日期的現行版本，而不是一份在工作坊結束翌日就開始與現實脫節的 PDF。
常見問題
流程繪製與流程建模有甚麼分別？
流程繪製產出的是一張人們真的會拿來用的圖：誰做甚麼、按甚麼次序、有哪些判斷和交接。流程建模產出的是一份形式化、受符號規範約束的表述——通常是 BPMN——工具可以對它作校驗或直接執行，它對事件類型、閘道和訊息流都有規則。大多數機構需要的是那張圖。只有當下游確實有東西要消費它時，例如一個工作流程引擎或一個自動化項目，才去動模型。
我應該畫現在的流程還是改善後的流程？
畫現在的，而且永遠先畫現在的。現狀圖是一份可以與執行工作的人一起驗證的事實紀錄，這令它成為一項共識而不是一種看法。有了它之後，未來流程圖不過是一次簡短又便宜的對話，談的是幾處具體改動。跳過現狀，就等於改善是針對一條假想的流程去設計的，而這個假想通常就是順利路徑。
繪製一條業務流程應該花多長時間？
對一條有四至五條泳道的單一營運流程來說：幾個小時的訪談、一個下午起草，再加一場驗證會。折合兩至三天的投入，分散在日曆上。凡是要花上幾個星期的，通常是範圍問題而不是複雜度問題——界線沒有釘死，於是圖不斷向旁邊的鄰接流程蔓延。
業務流程圖應該由誰負責？
一位可以修改它的具名人員，通常是流程負責人，而不是主持這次繪製的那個人。泳道負責人負責覆核；流程負責人負責維護。沒有唯一負責人，圖會以一種可預見的方式失效：它在技術上一直可用，卻悄無聲息地不再對得上現實，這比根本沒有圖更糟，因為大家仍然相信它。