跨部門流程交接圖怎麼畫？從觸發到結案找出等待點

以六步畫出可核對的跨部門泳道圖，從明確起訖、角色交接到等待、返工、資料來源與例外回流，並用一筆假設案例檢查責任交界。

跨部門流程的問題，常不在某一個人做得慢，而在工作交出去後，沒人知道對方何時接手、缺什麼資料，或退回後由誰補齊。泳道圖把角色放在不同軌道，讓每個動作、交接與回流都能對照實際紀錄。先挑一條反覆發生的流程，跟著一筆案件從觸發追到結案；不必先選繪圖軟體，也不必把每個細節塞進同一張圖。

界定流程起訖事件

先選一條真的會跨角色的流程，寫出起點和結案點，別從「公司怎麼運作」這種大題目開始。起點應是可觀察、可回查的觸發事件，例如收到客戶需求、員工送出請購或主管核准變更；「業務開始處理」太模糊，因為不同人會把開始理解成開信、建檔或第一次聯絡。終點也用可驗證事件表示，例如報價已寄出且版本存檔、申請人收到核准結果、問題單已通知提出者並關閉。若流程需要對方確認才算完成，就把確認納入；不要只因內部工作做完就寫結案。接著明確列入哪些入口、案件類型或狀態，哪些轉成另一種作業便停止追蹤；同一張圖若混了例行詢價、客訴和特殊合約，路徑會膨脹到無法核對。可先用一句話描述範圍：「收到完整詢價，到回覆核准報價為止」，並標明不包括後續簽約、收款。再指定一位流程負責人，確保跨部門對起訖有共識，另挑一筆近期已結案和一筆停滯中的紀錄，核對觸發時間、第一個動作與結束證據。若兩筆案例的起點不同，不急著把分歧抹平，先判斷是同流程的分支，還是其實有兩條流程。起訖寫清楚後，圖才有可比較的總歷時與樣本；後續每個等待和退回也能判斷是否仍在範圍內。設定起訖後，再用兩個問題測邊界：若案件在午休前收到、隔天才登錄，時鐘從哪裡開始？若主管口頭同意但沒有留下紀錄，算已核准還是仍在等待？答案應由可查證的事件決定，並在圖旁註明假日、撤回及重開案件是否納入。若不同類型的案件有不同起點，可先畫共同主線，再用分支標示特殊入口；不要把尚未確認的流程時限寫成標準。

標出各角色交接

把角色放成泳道前，先問「誰實際完成這一步」，不要只照組織圖列部門。常見做法是用橫向軌道表示業務、專案、財務、主管等角色，步驟沿著時間由左往右排；同一人兼任兩職時，可先保留角色軌道，避免工作責任隨人名異動而失焦。每個方框只寫一個動作與產出，例如「核對需求並補上規格」，不要寫成「處理客戶」這種看不出完成條件的描述。箭頭跨過泳道，代表責任真的移交；箭頭旁註明交付物、接收者及接手條件，例如「需求表已補齊，由專案確認範圍」。再補上交出方何時算完成、接收方何時必須回應，以及發現缺件時退給誰。這三點能區分「把檔案寄出」和「對方已接手」的差別。遇到共用信箱、值班人或外部窗口，仍要把實際接收的角色寫清楚，不能只畫一個沒有負責人的「部門」。若一個節點有多人核准，逐一畫出串行或並行條件，註記最後由誰彙整結果；不要用一條模糊箭頭掩蓋等待多人的情況。完成初稿後，請每個泳道的執行者確認自己真的做過圖上的動作，也請交接前後兩方互相說明交付物。只要一方說不出「我收到什麼才開始」，就先補上交接契約，再討論是否調整人力或工具。泳道顆粒度則看交接發生在哪裡：同一部門內若不同角色輪流接案，仍應分開；若只是同一人換了職稱而動作不變，可共用一條角色泳道。圖太寬時先只保留會改變責任或資料的步驟，重複又相同的細節可合併成子流程並記下展開處。每條線都要能回答誰現在持有案件；遇到「共同負責」要寫出決策或彙整的唯一承接者。

記錄等待與返工

把處理時間和等待時間分開記，否則「花了三天」無法說明究竟做了多少工作。每個重要步驟至少記下進入佇列、開始處理、完成交付的時間；若只方便取得日期，也要用一致的粒度，並標註資料不足。圖上可把等待畫成停留點或佇列，旁邊寫明等待誰、等什麼、從哪個事件開始計時，例如等主管批示、等客戶補尺寸。實際處理時間則記錄動手核對、整理或決定所花時間，不要把兩段相加後誤認為工作量。返工要用回箭頭回到真正重做的節點，並記錄退回原因、退回者、補件者、版本及再次送出的時間；「資料不完整」太籠統，應寫成可檢查的項目，例如缺少交期或圖檔版本。每次退回都保留原始交件狀態，才能分辨是交接標準不清、上游資料錯誤，還是需求後來改變。再看不同案件是否重複卡在同一人、同一欄位或同一批准條件。單一個案只能指出要追問的地方，不足以證明某部門造成瓶頸；可先把數筆案件並排比對，並保留例外原因。改善順序依影響面決定：先處理反覆出現、造成後續多次重做的缺口，再看偶發且容易恢復的停等。這樣標記後，討論會從「誰太慢」轉為「哪個條件讓案件停住」。可以先用一個簡單紀錄欄：案件代號、交接時間、接手時間、完成時間、等待原因、退回次數。比較時用同一種口徑，例如從資料齊全才開始計處理，否則不同人把等補件也算進處理時間，數字便不可比。圖不是績效排名表，數據用途是定位工作條件；先核對是否存在假日、案件難度或緊急插單差異，再決定是否修流程。

對照表單與訊息來源

交接時，把圖上的每個輸入都對回實際表單、郵件、訊息或系統欄位，確認資料從哪裡來、由誰維護、下游看到的是哪個版本。可另做一張欄位對照表：需求內容對應哪份文件、金額或日期以哪筆紀錄為準、異動由誰更新、接收者如何知道變更。若同一欄位散落在聊天訊息和試算表，先確認團隊現在依哪個來源作決定，不要直接假設最新訊息就是正式版本。圖中可用文件圖示或短標籤連到表單名稱與欄位，不必複製整份內容，也避免放入客戶個資、帳密或敏感附件。電子郵件、即時通訊、雲端文件、CRM 等都只是常見的記錄工具，是否適用要看團隊現行做法與權限；它們並不自動互通，也不代表任何特定整合已經存在。標出一份資料被重複輸入的位置：例如業務先在詢價表填寫，再由專案抄到任務清單，財務又從訊息取數。接著問每次轉錄是否必要、轉錯時誰能發現，以及更正後要通知哪些人。若表單沒有欄位承接某個必要決策，就在圖上標為資訊缺口，先修訂交接資料或規則，不要急著購買新工具。最後抽查一筆案件，從觸發附件一路核對到結案紀錄；若名稱相同但版本不同，應以識別方式說明版本來源，避免圖面看似完整，現場仍在猜哪份才有效。如果來源互相衝突，畫一條「更正」路徑：誰確認正確值、誰更新正式紀錄、誰收到通知。這可避免同一資料在多份文件被各自修正，之後又被舊版本覆蓋。欄位名稱也要保留現場用語，並在旁註內部定義，讓畫圖者與執行者談的是同一筆資料。

設計例外回流路徑

主流程只描述順利完成的路徑，真正暴露責任缺口的通常是例外。先從近期案件找出缺件、內容互相矛盾、核准未通過、承辦人不在或外部回覆延遲等情況；每一種都要畫出判斷條件，而不是只加一個「異常處理」方框。若缺件可補，箭頭回到提出資料的角色，寫清要補哪一項、由誰通知、補齊後回到哪個步驟；若條件不符，則標出拒絕或取消的決定者、通知對象與結案紀錄。遇到暫時無法處理的情況，指定暫存位置、追蹤責任人與重新檢查的觸發條件；重試次數和等待上限應依組織規則及風險訂定，不要為了圖面方便套用沒有依據的固定數字。對高風險決策，加入人工確認或升級路徑，並明確說明何時能回到主線、何時必須停止。回流箭頭要落在實際需要重做的節點，不要一律退回起點，否則無法知道已完成的工作哪些可沿用。也別讓例外分支在圖邊緣消失：每條分支都要有負責角色、狀態、通知及結束條件。流程負責人可定期檢查新增例外是否已納入圖中；若某個例外只需一次人工處理，先記錄即可，若多次出現，再評估是否修訂表單、權限或外部工具設定。分支不要只標「通知主管」，要寫明主管收到什麼資料後能判斷，以及決定結果如何傳回原承辦人。若例外涉及需要保留的決策紀錄，指定存放處和補記責任；若需要暫停對外回覆，標出誰有權解除暫停。流程變更時，保留圖面版本及生效條件，避免新舊規則同時被引用。這些資訊不必全部畫成複雜符號，可以使用短註記或側欄規則表，但必須能沿著箭頭找到負責人與出口。

用一筆樣本驗流程

先拿一筆已結案紀錄走圖，再拿一筆卡住或退回的紀錄測試分支。以下是明確假設的「客戶詢價至報價回覆」示例，角色與節點只用來展示畫法，不代表任何公司的實際流程或成效。從收到詢價表開始，逐步問：這一步誰做、輸入在哪裡、完成證據是什麼、交給誰？表格中的「等待」是要在實際抽樣時填入的觀察欄，不是通用時限。若某一步找不到證據，先回頭問執行者，不要在圖上補出理想流程。|步驟|泳道角色|交付與核對點|觀察| |---|---|---|---| |收到詢價|業務|詢價表有聯絡方式與需求|記錄觸發時間| |確認範圍|業務、專案|規格與交期已確認|補件時標回流| |核算報價|財務|依核准資料留存版本|分開記錄處理與等待| |主管核准|主管|結果及修改理由可查|記錄進出時間| |回覆並結案|業務|寄出版本已存檔|確認結案證據| 核對時，請執行者口述最近一次實際怎麼做，旁觀者同步移動箭頭；每遇到「我通常會問某某」或「檔案應該在某處」，就記成待確認，而非當作正式步驟。再故意挑一個真實例外，例如需求缺尺寸，確認圖上能指出通知人、補件欄位、回流節點與重新開始的條件。最後讓交出方和接收方各自讀一遍，核對責任交界是否一致；有爭議的地方保留兩種說法並指定查證紀錄，不用現場投票決定真相。若口述與紀錄不一致，先追查差異；若它影響起訖或責任，就標待確認，補看另一筆同類案件後再定稿。下一步可從最近一筆案件開始，畫出六個欄位：觸發、角色、交付物、等待、返工、結案證據，再把需要延伸了解的方向放到 ZhenheAI 首頁。