導入與驗收
BPM 導入時程、POC 與驗收怎麼安排？
慧智科技知識中心 ·
導入時程問的不是「要幾個月」，而是「每個階段要產出什麼、由誰確認」。用可交付的產出定義進度，比用完成百分比估算更能看出專案實際走到哪裡。
最後更新：
導入要拆成哪些可驗收的階段？
同樣是「導入 BPM」，一條費用申請流程與二十條跨部門流程的工作量差距極大。因此估時程之前，要先確定範圍：這次要上線幾條流程、各自有幾個關卡、需要與哪些系統介接、是否包含歷史資料轉換。範圍沒定，任何時程數字都只是猜測。
比較務實的做法是先以一條代表性流程走完整個週期，取得實際節奏後，再推估其餘流程。第一條流程通常最慢，因為權限模型、組織資料與介接方式都在這時候才真正確定下來。
每個階段該產出什麼？
| 階段 | 主要工作 | 可交付產出 | 常見延誤原因 |
|---|---|---|---|
| 需求盤點 | 釐清流程步驟、角色、核決規則與例外處理。 | 流程說明、核決權限表、表單欄位清單。 | 核決規則只存在於慣例，沒有書面依據，需先對齊。 |
| 介接確認 | 確認要交換的資料、介面方式、帳號權限與失敗處理。 | 整合清單、測試帳號、範例資料。 | 既有系統無可用介面，或窗口不在專案編制內。 |
| 建置與設定 | 建立表單、流程、權限與報表，設定組織資料。 | 可操作的測試環境、流程定義版本。 | 組織圖與人事資料未同步，簽核人解析不到。 |
| POC 或試辦 | 以真實案件驗證流程、介接與稽核紀錄。 | 驗收清單結果、問題列表與處理方式。 | 使用真實案件時才發現例外情境未涵蓋。 |
| 教育訓練 | 依角色說明操作、代理設定與異常處理。 | 操作說明、常見問題、聯絡窗口。 | 訓練時間與月結、年度稽核等尖峰期重疊。 |
| 上線與觀察 | 正式發布、監看案件狀態與停留時間。 | 上線紀錄、初期問題追蹤表。 | 未預留觀察期，問題與下一批流程開發互相排擠。 |
POC 該驗收哪些項目？
POC 的價值不在於「看起來能跑」，而在於用真實條件暴露問題。建議至少涵蓋下列項目，並要求以實際案件而非示範資料演示：
- 核決路徑正確性：不同金額、不同部門的案件，是否解析到預期的簽核人。
- 例外與退回：退回、補件、轉派與代理人情境是否留下可查紀錄。
- 整合往返：核准後資料是否正確寫入目標系統，失敗時如何得知與重試。
- 稽核軌跡：能否還原誰在何時做了什麼決定、資料改過幾次。
- 效能條件：以預期的同時使用人數與案件量測試，記錄回應時間。
- 變更影響：調整核決金額或組織後，既有案件與新案件的行為是否符合預期。
驗收清單要在 POC 開始前雙方確認，並載明每一項的通過條件。事後才補清單，容易變成各說各話。
最常見的延誤來自哪裡？
從產出的角度看，延誤幾乎都集中在兩件事：核決規則沒有書面依據，以及組織與人事資料不同步。前者讓需求盤點反覆確認，後者讓簽核人解析不到、流程停在半路。這兩項建議在專案啟動時就列為前置條件，而不是等建置階段才處理。
第三個常被低估的是介接窗口。資料交換牽涉的系統往往由不同單位維護，若窗口不在專案編制內，等待回覆的時間會直接累加到時程上。
常見問題
BPM 導入通常要多久？
沒有通用答案，取決於流程數量、關卡複雜度、整合範圍與企業內部的確認程序。建議先以一條代表性流程走完整個週期，取得實際節奏後再推估其餘流程。
POC 和試用有什麼不同？
試用多半用示範資料確認操作方式；POC 應以真實案件與真實核決規則驗證，並有事先議定的驗收清單與通過條件。
可以先上線一條流程再逐步擴充嗎？
可以，且是常見作法。第一條流程會把權限模型、組織資料與介接方式確定下來，後續流程的建置速度通常明顯提升。
導入前最該準備什麼？
準備去識別化的表單、書面的核決權限表、系統整合清單與希望追蹤的報表；並確認組織與人事資料的維護方式與更新頻率。
下一步
把一條實際流程的表單、核決規則與整合清單整理出來，就足以開始討論範圍與時程。選型階段要確認的項目可參考 如何挑選企業 BPM 系統；若還在比較工具類型，可先閱讀 BPM 與 RPA 的差別與搭配。