流程自動化之前：先重整例外、審批與交接

先把真實工作重新設計，才把它交給規則、機械人或人工智能。想像一項申請由電郵進入，資料被重新輸入另一系統，收集一個不會改變結果的簽名，在幾個隊列之間輪候，最後因欠缺證據而退回；原封不動地自動化，只會令同一套含糊安排走得更快。實施前，團隊要界定一類重複個案，核對正常及偏差路徑，逐項說清目的、負責人、決定、證據、驗收與復原，再為每個元素選定刪除、標準化、釐清或保留人手覆核。

自動化前的現況圖應顯示甚麼？

現況圖應顯示一類重複個案由可觀察觸發點走到下游使用者接受成果的實際路徑，而不是預先畫出某個平台的畫面。不預設解決方案的流程文件，可在選定技術前呈現起點、終點、參與角色、決策、順向任務及任務細節。現況分析應先於未來狀態設計，並以所選範圍的定量及定性證據為本。先限定一個個案類型、一個起點及一個可驗收終點；只有觀察所得的上游或下游依賴確實影響結果，才擴闊邊界。

• 步驟及其業務目的
• 觸發或進入條件
• 執行角色
• 輸入、來源及有效版本
• 規則、決定或動作
• 輸出及下游使用者
• 使用的系統或渠道
• 實際處理時間及輪候時間
• 完成步驟的證據
• 下一負責人及其驗收條件

不要只訪問流程擁有人。把程序、表格及控制描述，與近期完成個案、前線走查、支援紀錄、審計發現、退件及事件資料互相核對；設計原意與系統留下的次序是互補證據，不能互相取代。價值流程圖區分前置時間與週期時間，也記錄資訊流及完整準確程度；這些概念可審慎套用於服務流程。事件紀錄通常至少要有個案識別碼、活動名稱及時間戳，但這三項資料不會證明覆蓋完整、資料可靠或延誤成因。

哪些偏差是標準變體，哪些才是真正例外？

區分方法是先看偏差能否以穩定條件安全重複處理，而不是一律塞入「例外」隊列。BPMN能表達活動、參與者、訊息、閘道、計時、錯誤、升級及邊界事件，讓替代路徑和故障路徑變得可見，卻不會替團隊決定商業處置。經常出現的合理變體，只有在進入條件、步驟、負責人、證據和結果都穩定時，才適合改成標準分支；頻率本身並不足夠。

• 輸入不全或無效：資料、證明、格式、身份或先決條件欠缺、矛盾或過期。
• 已知業務變體：某類服務、地區或風險層級有合法而可重複的不同路徑。
• 政策或權限例外：要求超出規則、授權、容許幅度或已批准邊界。
• 容量、依賴或時間故障：負責人、上游服務或所需資源未能按本地期望提供。
• 技術執行故障：整合或資料移動逾時、拒絕、重複、局部完成或留下不確定狀態。

例外登記冊要寫下可觀察觸發、代表個案、已知期間內的頻率、後果、安全回應、復原負責人、獲授權邊界、所需證據、結果及持久紀錄，也要追問復發源頭屬輸入、規則、容量、政策、系統還是正常路徑本身。例外量偏高或偏低都只應視為診斷訊號，而不是處置結論。側渠道、錯誤分類、未記錄變通及真正高度多變的工作，都可能產生相似數字。標準化工作把既定次序寫成可改善的基準，情況轉變時仍要重新檢視。

甚麼審批才值得保留？

值得保留的審批，必須作出一個具名而可改變後續狀態的決定，並有可說明的風險、政策、資源或控制目的。控制活動應配合目標、已評估風險、營運環境、複雜程度，以及資料的敏感度和價值。先列出可選結果，例如批准、拒絕、退回、附帶條件或升級；一個不能改變下一狀態的步驟，可能是知會、確認、諮詢或提供證據，而未必是審批。延誤或圖上看似重複，都不是單獨刪除控制的理由。

• 確切要作出的決定及所有可用結果
• 所處理的風險、政策、資源或控制目的
• 審批角色及獲授權邊界
• 所需能力、獨立性或職責分隔
• 決定當刻可取得的完整相關證據
• 判斷準則或有限度酌情權
• 身份、時間、理據、條件及下游狀態紀錄

比較兩道關卡時，要確認它們是否以相同證據處理相同決定和風險，以及保留其中一道會否削弱必要控制。授權應由在權限範圍內行事的人作出；適當的文件及職責分隔，則可保留證據並分開授權、處理、記錄與覆核責任。自動、部分自動及人手控制可以並存，包括由人員回應系統標示或作出授權；單憑自動化並不能證明控制有效。若流程使用人工智能，角色、系統限制、任務脈絡、風險承受度、監督責任及人員使用輸出的方式，都應納入部署決定。

交接在甚麼時候才真正完成？

交接只有在具名接收者接受責任、收到足夠資料，並能開始下一行動時才算完成。BPMN區分參與者與訊息流，也能表示跨組織邊界的人手任務、資料、事件及流程狀態轉變。保留的交接應列明個案、發送角色、接收負責人、所需資料與證據、驗收條件、下一行動和例外路徑。電郵已寄出、工作已轉入共享隊列或系統已發通知，只能證明發送事件，不會自行證明責任已轉移。

• 個案身份及目前狀態
• 發送角色與具名接收負責人
• 必需資料、附件及有效版本
• 上一個步驟已完成的證據
• 接收方可檢查的驗收條件
• 預期下一行動及本地服務期望
• 資料不全、有爭議、逾時或錯誤路由的處理路徑
• 接受時間及可持久查閱的紀錄位置

量度亦要由接收而不是發送出發。交接輪候應由「可供轉交」量至「接收方接受負責」，並與實際處理時間分開。另行觀察因資料欠缺而退回的轉交、個案經過的負責人或隊列數目、未接受工作的存放時間、本地服務期望違反、具個案證據的下游重做，以及在已繪系統以外完成的工作。控制紀錄可讓重要事件及控制運作接受檢查，但紀錄存在不代表原來決定正確，也不證明控制有效。

每個流程元素應如何重整？

每個已繪元素只應取得一種明確處置：刪除、標準化、釐清或保留人手覆核。刪除、標準化、釐清及保留人手覆核，是本文把整體流程改善、標準工作、明確管治、風險控制與人手監督綜合而成的四種處置；引用機構並沒有共同訂立這套命名。這個限制迫使團隊說明證據與理由，避免以含糊的「稍後自動化」或「全部升級」掩蓋未完成的設計決定。

以一項新的第三方商業服務內部申請為例：若經理簽名只表示「已知悉」，不作資源、權限或風險決定，而業務發起人已有紀錄，可考慮刪除；把必填資料、個案身份、重複檢查、服務分類、證據清單及正常路由標準化；釐清誰接收不完整申請、誰處理各類偏差，以及設定團隊何時正式接受；涉及資源承擔、政策例外或按風險觸發的專業及獨立覆核，則交由獲授權人員決定。實際角色和要求仍以機構政策、合約、適用法律及風險評估為準。

不要自動化一幅承襲下來的流程圖；先重整令流程成立的決定、證據、例外與責任。

標準化提供一致執行和改善的明確基準，卻不證明所有個案都屬於標準路徑。處理控制時亦不應把「人手」與「自動」當作質素替代詞；預防與偵察控制的合適組合取決於脈絡、可能性、影響及已評估風險，而非一律偏好人手或自動操作。凡擬刪除涉及法律、規例、合約、政策、審計承諾、安全責任或既定風險框架的控制，都要先交由機構內合資格並獲授權的相關角色評估。

甚麼證據顯示流程已準備好實施？

流程只有在正常與故障路徑均有負責人、證據、控制、驗收、復原及合比例監察時，才具備作出條件式推行決定的基礎。用於記錄的流程模型可以不是可執行模型，而實施需要額外的正式細節；一幅清楚的現況圖本身並非可直接實施的規格。實施前應以有代表性的正常、資料不全、拒絕、邊界、逾時、改判、重做及技術故障個案走查建議流程，並在有紀錄時對照實況。

• 每個例外都有可觀察觸發、安全回應、決定或復原負責人、所需證據及結果紀錄。
• 每項審批都有獨特決定、控制目的、權限、所需能力或獨立性、證據、結果及下游狀態。
• 每個交接都有接收負責人、完整證據、驗收條件，以及處理資料不全或未獲接受工作的路徑。
• 擬刪除控制已有理據紀錄，並取得機構內適當的內部監控覆核。
• 權限、觸發人手覆核的情況、變更負責人及自動化邊界已寫入設計。
• 技術故障路徑要在實施前訂明重試安全、防止重複、對賬、補救、人手復原權限、證據及停止條件。
• 退件、重複例外、改判、隊列增長、缺陷及側渠道都有量度方法與覆核負責人。
• 推行決定可明確記錄為推行、修改後再審或停止，而不是把所有缺口留待上線後處理。

控制設計、文件、授權、職責分隔，以及預防與偵察活動的平衡，都應回應機構目標和已評估風險。加入人工智能時，情境知識、責任、系統限制、人手監督及風險承受度，應共同影響是否部署。法律、監管、財務、保安、私隱、安全、採購、人力資源及其他專業事項，應由機構內合資格並獲授權的角色處理。若政策、授權、獨立性、風險承擔、證據或專業判斷仍有重大未決問題，便應停止實施並先解決問題。