如何繪製流程中的交接
如何繪製流程中的交接：找出工作每一次易手的位置，寫下接收方是怎樣被告知的，並量度那段等候。附一個可即時操作的員工離職示例。
繪製交接，就是找出工作每一次易手的位置，寫下接收團隊是怎樣知道自己有工作的，並量度它在有人動手之前等了多久。
簡而言之
- 大多數流程的周期時間是團隊之間的排隊時間，而不是團隊內部的作業時間。
- 每一次交接都有一套觸發機制、一段等候時間和一個受理條件。
- 「他們會看共用電郵信箱」是一個沒有負責人的隊列，不是一套觸發機制。
- 把跨越次數數出來：次數太多說明工作切分錯了，而不是畫錯了。
- 遲到代價高昂的交接，應該畫成決策，而不是步驟。
工作並不是停在某個步驟裏
把任何一條營運流程端到端量一遍，算出來的帳通常都不好看：作業只需幾個小時，流程卻要幾天。這個差額不是步驟內部效率低。它是步驟之間的空隙——一個團隊做完了、下一個還未開始、當下沒有任何人把這件事項當成自己的，就是那段時間。這些時間段就是交接，而它們幾乎從不被記錄下來，因為沒有任何單一團隊親身經歷過它們。
交接不是一支箭嘴。它是一個事件，有三條值得寫下來的屬性：觸發機制（接收方是怎樣發現的）、等候時間（他們隔多久才動手），以及受理條件（他們要有甚麼才可以開始）。一次畫成普通直線的流轉，暗示這三樣都是即時而完整的——而恰恰是這個假設，造就了一條人人都覺得沒問題的流程，和一位仍在等候的客戶。
以下示例是員工離職，它幾乎由頭到尾都是交接：人力資源到主管，主管到 IT，IT 回到人力資源，然後是薪酬和後勤。它還包含整個人力資源範疇裏遲到代價最高的那一次交接——當日撤銷權限——這也正是它被畫成一個決策、而不是留成一個總有人會去做的步驟的原因。
一條幾乎全是交接的流程
跨人力資源、主管、IT、薪酬與後勤的員工離職流程。留意工作易手的頻率有多高。
第一次跨越就開始計時
辭職或解僱通知到達人力資源，按主動離職與被動離職分成兩支，最後一個工作日由主管確認。下游所有期限都掛在這個日期上，所以傳遞這個日期的那次交接，正是值得計時的那一次。
不能遲到的那次交接
「是否需要即時中斷權限？」會通向當日撤銷。把它畫成決策而不是步驟是刻意的：這樣就迫使某個人在第一日回答這個問題，而不是把它留在一份 IT 要到星期四才看到的清單裏。
會被打回頭的交接
工作移交方案、項目轉手和操作手冊更新都在主管手上，隨後是一次可以把整件事退回去的簽核決定。一次被退回的交接是第二次跨越，而這一次沒有人數進去，離職流程通常亦正是在這裏超時的。
最後一日同時行動的三個團隊
人力資源做離職面談、薪酬部門結算最後一期薪金、後勤回收資產，最後由 IT 撤銷餘下權限——並有一條資產未歸還時退回薪酬的路徑。四條泳道在同一日行動，只有在每一方都知道那個日期時才成立，於是又回到第一階段。
人走之後的那些交接
最後一期薪金發放，紀錄按保存政策歸檔。離職流程裏最常缺失的就是離職之後的這些步驟，因為到那時已經沒有人在催，而本來會察覺問題的那個人已經走了。
運作方式
先用泳道把流程畫出來
只有當流程按負責人切開之後，交接才會顯形。把每個步驟放進執行它的那個角色的泳道裏——在 QueryChart 裏就是「垂直泳道」欄——那些跨越就會自己浮出來，不需要任何人專門去找。
標出每一條越過泳道的連線
一條一條走過去，把它們列成清單。一條十五個步驟的流程跨越泳道八次，是很正常的，也值得知道；這個數字本身往往是整個練習裏最有說服力的東西，正因為從來沒有人見過它。
寫下接收方是怎樣被告知的
對每一次跨越，把觸發機制寫進這個步驟的備註裏：系統裏的一次狀態變更、一張指派過來的工單、一封電郵、一個共用隊列、一次站立會議。凡是誠實答案是「他們自己會看」的地方，你就找到了一個沒有負責人的隊列，和一段沒有人在量度的等候。
寫下接收方要有甚麼才可以開始
受理條件和觸發機制同樣重要。沒有確認的日期，IT 無法開通或回收；不知道資產歸還情況，薪酬無法結清。交接失敗，出在資訊不完整上的次數不比出在通知太遲上的少，而這兩者的解法並不相同。
為等候時間計時，哪怕很粗略
問每一個接收團隊：一件事項通常放多久他們才會接手。粗略數字就夠了——重點是形態，而這個形態幾乎總是：一兩次跨越佔掉了大部分的實際耗時。把數字寫在步驟上。
先修機制，再改流程
大多數交接問題靠改觸發機制就能解決——用一條通知取代靠人自己去看，用一個有具名負責人的共用隊列取代一個電郵信箱——而不是靠搬動工作。只有當這次跨越根本就不應存在時，才去重新設計流程。
應避免的錯誤
把交接畫成一支普通箭嘴
一次沒有任何註解的跨越，暗示的是即時而完整的移交。那些不見了的日數，就藏在這個假設裏。
數步驟而不是數跨越
步驟數告訴你有多少工作量。跨越數告訴你它要花多長時間。兩者經常毫無關係。
在一條泳道內部做優化
把某個團隊自己的步驟做快很有滿足感，而且通常甚麼也改變不了，因為事項一生中的大部分時間是在泳道之間，而不是在泳道裏面。
想當然地認為接收方知道
「他們在系統裏看得到」只有在真的有人去看時才算觸發機制。要問他們甚麼時候看，以及多久看一次。
繪製你們自己的交接
把員工離職示例開啟為你自己的圖表，重新命名泳道，並在每一次跨越上註明下一個團隊是怎樣被告知的。
相關指南
常見問題
甚麼是流程交接？
它是一件工作的責任由一個人、一個團隊或一個系統轉到另一方的那個點。它有三個值得記錄的部分：接收方是怎樣被通知的、他們要有甚麼才可以開始，以及在他們動手之前這件事項等了多久。交接之所以影響格外大，是因為沒有任何單一團隊親身經歷它——發送方認為工作已經完成，接收方還未開始，於是這段空隙不屬於任何人，也沒有任何人在量度它。
我怎樣找出一條流程裏的交接？
按每個負有問責的角色一條泳道把流程畫出來，然後把每一條跨越泳道界線的連接都列出來。那就是完整的清單。任何其他做法——問大家延誤在哪裏、翻工單——找到的都是那些已經引起投訴的跨越，而會漏掉那些只是慢的。在 QueryChart 裏，泳道歸屬就是試算表裏的一欄，所以這些跨越可以直接由那些列點算出來。
交接多少次算太多？
沒有一個絕對數字，但比例很說明問題：如果一條十五個步驟的流程跨越泳道十次，那麼工作幾乎每一步都在易手，責任的切分很可能是錯的。去找一條本來可以整體承擔一段連續區塊的泳道，而不是讓它把同一件事項接進來又送出去兩遍。減少跨越次數，通常勝過把其中任何一次做快。
怎樣縮短交接造成的延誤？
先改觸發機制，再改流程。大部分延誤來自接收方不知道有工作——一個沒有人負責的共用電郵信箱、一個沒有人盯的狀態欄位——把它換成一條真正的通知，或者一個有具名負責人的指派隊列，就能在完全不動誰做甚麼的前提下把等候消掉。只有當一次跨越根本不應存在時，才去重新設計流程；而當它必須存在時，就給它一位負責人。
