如何繪製流程中的交接
如何繪製流程中的交接：找出工作每一次易手的位置，寫下接收方是怎樣被告知的，並量度那段等候。附一個可即時操作的員工離職示例。
運作方式
先用泳道把流程畫出來
只有當流程按負責人切開之後，交接才會顯形。把每個步驟放進執行它的那個角色的泳道裏——在 QueryChart 裏就是「垂直泳道」欄——那些跨越就會自己浮出來，不需要任何人專門去找。
標出每一條越過泳道的連線
一條一條走過去，把它們列成清單。一條十五個步驟的流程跨越泳道八次，是很正常的，也值得知道；這個數字本身往往是整個練習裏最有說服力的東西，正因為從來沒有人見過它。
寫下接收方是怎樣被告知的
對每一次跨越，把觸發機制寫進這個步驟的備註裏：系統裏的一次狀態變更、一張指派過來的工單、一封電郵、一個共用隊列、一次站立會議。凡是誠實答案是「他們自己會看」的地方，你就找到了一個沒有負責人的隊列，和一段沒有人在量度的等候。
寫下接收方要有甚麼才可以開始
受理條件和觸發機制同樣重要。沒有確認的日期，IT 無法開通或回收；不知道資產歸還情況，薪酬無法結清。交接失敗，出在資訊不完整上的次數不比出在通知太遲上的少，而這兩者的解法並不相同。
為等候時間計時，哪怕很粗略
問每一個接收團隊：一件事項通常放多久他們才會接手。粗略數字就夠了——重點是形態，而這個形態幾乎總是：一兩次跨越佔掉了大部分的實際耗時。把數字寫在步驟上。
先修機制，再改流程
大多數交接問題靠改觸發機制就能解決——用一條通知取代靠人自己去看，用一個有具名負責人的共用隊列取代一個電郵信箱——而不是靠搬動工作。只有當這次跨越根本就不應存在時，才去重新設計流程。
常見問題
甚麼是流程交接？
它是一件工作的責任由一個人、一個團隊或一個系統轉到另一方的那個點。它有三個值得記錄的部分：接收方是怎樣被通知的、他們要有甚麼才可以開始，以及在他們動手之前這件事項等了多久。交接之所以影響格外大，是因為沒有任何單一團隊親身經歷它——發送方認為工作已經完成，接收方還未開始，於是這段空隙不屬於任何人，也沒有任何人在量度它。
我怎樣找出一條流程裏的交接？
按每個負有問責的角色一條泳道把流程畫出來，然後把每一條跨越泳道界線的連接都列出來。那就是完整的清單。任何其他做法——問大家延誤在哪裏、翻工單——找到的都是那些已經引起投訴的跨越，而會漏掉那些只是慢的。在 QueryChart 裏，泳道歸屬就是試算表裏的一欄，所以這些跨越可以直接由那些列點算出來。
交接多少次算太多？
沒有一個絕對數字，但比例很說明問題：如果一條十五個步驟的流程跨越泳道十次，那麼工作幾乎每一步都在易手，責任的切分很可能是錯的。去找一條本來可以整體承擔一段連續區塊的泳道，而不是讓它把同一件事項接進來又送出去兩遍。減少跨越次數，通常勝過把其中任何一次做快。
怎樣縮短交接造成的延誤？
先改觸發機制，再改流程。大部分延誤來自接收方不知道有工作——一個沒有人負責的共用電郵信箱、一個沒有人盯的狀態欄位——把它換成一條真正的通知，或者一個有具名負責人的指派隊列，就能在完全不動誰做甚麼的前提下把等候消掉。只有當一次跨越根本不應存在時，才去重新設計流程；而當它必須存在時，就給它一位負責人。