業務流程模型與符號，或BPMN，是一種標準化的視覺語言，用於描述工作如何完成。它幫助業務分析師、經理、開發人員和流程參與者理解相同的流程，而無需依賴冗長的書面程序。
一個BPMN圖表由四個廣泛的類別構成：
-
流程對象：事件、活動和網關
-
連接對象：順序流、訊息流和關聯
-
泳道：池和泳道
-
圖元：資料對象、群組和文字註解
本指南專注於最重要的類別：BPMN流程對象。流程對象描述流程中發生的事、執行的工作，以及流程如何從一個路徑轉移到另一個路徑。
1. 什麼是BPMN流程對象？
流程對象是BPMN流程圖的核心元素。它們通過順序流相連，並代表流程的行為。
共有三種類型：
| 流程對象 | 基本形狀 | 主要目的 |
|---|---|---|
| 事件 | 圓形 | 某件發生的事 |
| 活動 | 圓角矩形 | 執行的工作 |
| 網關 | 菱形 | 一個決策、分支、合併或同步點 |
一個簡單的流程在概念上可能看起來像這樣：
開始事件 → 活動 → 網關 → 活動 → 結束事件
例如：
收到訂單 → 檢查庫存 → 該商品有庫存嗎？
├── 是 → 發貨訂單
└── 否 → 通知客戶
這些形狀很簡單，但其內部的符號提供了額外的含義。
2. 事件：發生的事
一個事件代表流程過程中發生的某件事。與活動不同，事件並非由個人或系統執行的工作。它可能觸發一個流程、中斷一個活動、表示某種條件，或說明流程如何結束。
事件以圓圈表示。邊框表示事件在流程中發生的位置：
| 事件類型 | 邊框外觀 | 含義 |
|---|---|---|
| 開始事件 | 細單線 | 顯示流程如何開始 |
| 中間事件 | 雙線 | 發生在開始與結束之間 |
| 結束事件 | 粗單線 | 顯示流程路徑如何結束 |
開始事件可以捕獲觸發條件，例如收到訊息或到達預定時間。中間事件可能等待或發送某種訊號。結束事件產生流程路徑的最終結果。
2.1 開始事件
一個開始事件表示啟動流程或子流程的觸發條件。
它以邊框較細的圓圈繪製。
常見的例子包括：
-
客戶提交訂單
-
員工提交休假申請
-
計時器達到預定日期
-
訊息到達
-
系統檢測到一個條件
-
建立新案件
無起始事件
一個普通的起始圓圈表示流程在沒有明確建模觸發條件的情況下開始。
○
範例：
○ → 審核申請
當精確的觸發條件未知、不相關或有意保持一般性時，請使用無起始事件。
訊息起始事件
起始事件內的訊息符號表示流程在收到訊息時開始。
範例：
◉ 信封符號 → 處理客戶請求
常見使用案例：
-
接收電子郵件
-
接收API請求
-
接收採購訂單
-
接收來自其他參與者的請求
計時器開始事件
開始事件內部的時鐘表示該流程將根據計畫或日期啟動。
範例：
-
每月啟動發票生成
-
在到期前30天啟動續約流程
-
執行每日對帳流程
條件式開始事件
當業務條件成立時，條件式開始事件即啟動。
範例：
庫存水位低於補貨點
訊號開始事件
當收到廣播訊號時，訊號開始事件即啟動。與訊息不同，訊號通常不會指向單一特定接收者。
範例：
接收「緊急關閉」訊號 → 關閉所有分支機構
多重開始事件
多重開始事件表示多個不同的觸發條件可啟動同一流程。
例如，支援案件可能在以下情況下啟動：
-
客戶提交網路表單
-
客服人員手動輸入案件
-
自動監控系統檢測到一個問題
2.2 中間事件
一個中間事件在流程開始後、結束前發生。它可以暫停流程、等待某件事、發送訊息、建立例外路徑，或回應某個條件。
它以雙重邊框繪製。
中間事件可以是：
-
捕獲：等待或接收某樣東西
-
拋出：發送或產生某樣東西
捕獲事件通常使用未填滿或空心的標記，而拋出事件通常使用實心標記。
計時器中間事件
計時器事件代表延遲、截止期限、持續時間或重複的時間表。
範例：
-
等待三個營業日
-
等待到特定日期
-
若24小時內無回應，則升級處理
-
在流程運行期間執行重複動作
範例：
發送報價 → 等待3天 → 檢查回應
訊息中間事件
訊息中間事件會等待訊息或發送訊息。
範例：
發送批准請求 → 等待批准回應
訊息事件在流程與其他參與者、部門、組織或系統互動時特別有用。
錯誤中間事件
錯誤事件代表影響正常流程的錯誤狀況。
它通常用作附加到活動或子流程的邊界事件。
範例：
處理付款
│
└── 錯誤 → 處理付款失敗
升級中間事件
升級事件表示某問題需要在更高層級獲得關注，而不一定代表技術故障。
範例：
解決客戶投訴
│
└── 升級 → 主管審核
條件中間事件
條件事件會等待指定條件變為真。
範例：
等待客戶帳戶驗證完成
信號中間事件
訊號事件會廣播或接收可能與多個流程參與者相關的訊號。
範例：
廣播產品召回訊號
連結中間事件
連結事件可在同一流程圖內連接兩個遠距離點，而無需在頁面上繪製一條長長的順序流線。
應謹慎使用連結事件。它們可以提升圖表的可讀性，但過度使用可能會使流程更難追蹤。
補償中間事件
補償事件會觸發修正工作，以撤銷或補償先前的活動。
範例：
取消酒店預訂
補償與一般的錯誤路徑不同。它專注於撤銷或補償已完成的工作。
2.3 边界事件
一個邊界事件直接附著於活動或子流程的邊緣。它代表在該活動進行期間可能發生的某種事件。
範例：
┌────────────────────┐
│ 流程應用程式 │
└────────────────────┘
○
│
└── 超時 → 升級案例
邊界事件適用於建模：
-
逾時
-
取消
-
錯誤
-
升級
-
傳入訊息
-
補償
-
外部信號
中斷邊界事件
當中斷邊界事件發生時，會停止附著的活動。
範例：
處理付款
│
└── 付款錯誤 → 處理失敗
當錯誤發生時，付款活動結束。
非中斷邊界事件
非中斷邊界事件會在原始活動繼續進行的同時，啟動額外的路徑。
通常以虛線邊框顯示。
範例：
處理申請
│
└── 定時提醒 → 發送提醒
申請流程在提醒路徑執行時繼續進行。
此區別很重要：
| 邊界事件類型 | 對附著活動的影響 |
|---|---|
| 中斷 | 停止活動 |
| 非中斷 | 保持活動運行 |
2.4 結束事件
一個結束事件表示流程路徑的結束。它以一個粗邊的圓形繪製。
一個流程可能有超過一個結束事件，因為不同的結果可能終止流程。
範例：
-
訂單完成
-
請求被拒絕
-
付款失敗
-
案件取消
-
客戶已通知
-
流程以補償完成
無結束事件
一個普通的結束事件表示該路徑已完成，但未指定特定結果。
●
訊息結束事件
訊息結束事件在流程結束時發送訊息。
範例：
訂單已批准 → 發送確認 → 消息結束
錯誤結束事件
錯誤結束事件會透過將錯誤傳送到上層流程或處理常式來結束流程。
用於必須在其他地方處理的流程層級失敗條件。
升級結束事件
升級結束事件會結束目前的流程路徑，並傳達已發生升級的訊息。
終止結束事件
終止結束事件會立即結束整個流程實例，包括其他活躍的路徑。
這比一般的結束事件更強力。當所有剩餘工作都必須停止時，應使用此事件。
補償結束事件
補償結束事件會在流程路徑結束前觸發補償活動。
3. 活動：執行中的工作
一個 活動代表由個人、團隊、系統或自動化服務執行的工作。活動以圓角矩形表示。
範例包括：
-
審核申請
-
批准發票
-
發送確認
-
驗證客戶資料
-
計算運費
-
更新帳戶
-
產生報告
活動構成BPMN圖表的運營核心，因為它們顯示了時間、努力、成本和責任集中的地方。
3.1 活動命名
良好的活動名稱通常遵循以下模式：
動詞 + 名詞
範例：
-
審核申請
-
批准發票
-
建立客戶記錄
-
驗證付款
-
發送確認郵件
避免使用模糊的名稱，例如：
-
處理
-
處理請求
-
步驟 1
-
其他工作
-
行政
明確的活動名稱應描述一個動作及其主體。
| 弱名稱 | 較佳名稱 |
|---|---|
| 處理中 | 處理付款 |
| 審核 | 審核申請 |
| 客戶步驟 | 驗證客戶身分 |
| 電子郵件 | 發送批准電子郵件 |
| 更新 | 更新訂單狀態 |
任務通常代表一個無法或不應進一步分解的工作單位。子流程代表一組相關活動的集合。
3.2 任務
一個 任務是最簡單的活動類型，代表單一的工作單位。
基本任務以圓角矩形顯示：
╭────────────────────╮
│ 審核申請 │
╰────────────────────╯
任務可能包含標記，用以識別正在執行的工作類型。
使用者任務
使用者任務是由人類使用系統或應用程式執行的。
範例：
-
批准費用報表
-
輸入客戶資訊
-
審查合約
-
指派支援案件
手動任務
手動任務是由個人在沒有商業流程引擎或應用程式協助的情況下執行的。
範例：
-
檢查設備
-
簽署紙質文件
-
包裝實體產品
-
親手遞送文件
服務任務
服務任務由系統、應用程式、網路服務或 API 自動執行。
範例：
-
取得信用分數
-
發送自動化郵件
-
計算稅款
-
建立資料庫記錄
-
呼叫付款服務
腳本任務
腳本任務會在流程環境中執行腳本或程式碼片段。
範例：
-
轉換資料
-
計算一個值
-
格式化訊息
-
套用簡單的資料規則
商業規則任務
商業規則任務會評估商業規則，通常透過規則引擎進行。
範例：
-
決定信用額度
-
計算保險費
-
決定訂單是否符合免運條件
-
決定核准等級
傳送任務
傳送任務會將訊息傳送給另一參與者或系統。
範例：
-
發送發票
-
發送訂單確認
-
發送通知至倉庫
接收任務
接收任務會等待來自其他參與者或系統的訊息。
範例：
-
接收已簽署的合約
-
接收付款確認
-
接收運送狀態
3.3 子流程
一個子流程是一個包含更詳細流程的活動。
它可以用兩種方式呈現：
-
收縮的子流程： 帶有加號標記的圓角矩形
-
展開的子流程： 一個較大的圓角矩形，顯示內部流程
當多個任務彼此相關，且若將所有任務都顯示在高階圖表中會導致過於複雜時，應使用子流程。
範例：
╭──────────────────────────────╮
│ + 完成客戶開通流程 │
╰──────────────────────────────╯
子流程可能包含：
收集資訊
↓
驗證身份
↓
建立帳戶
↓
發送歡迎訊息
何時使用子流程
在以下情況下使用：
-
一組步驟具有明確的商業目的
-
該組步驟在概念上可能被重複使用
-
主圖表變得過於擁擠
-
利益相關者需要同時擁有概覽與詳細視圖
-
內部流程具有自己的開始、結束、例外或決策邏輯
內嵌子流程
內嵌子流程是在其父流程內部定義的，並屬於該流程的流程的一部分。
呼叫活動
呼叫活動會調用一個獨立定義的可重用流程或全域任務。
當相同的流程邏輯從多個地方被調用時，請使用它，例如：
驗證客戶身份
如果客戶驗證出現在多個業務流程中，使用可重用的呼叫活動可能比重複所有內部步驟更合適。
事件子流程
事件子流程在包含它的流程或子流程處於活躍狀態時，由開始事件觸發。它適用於處理異常或並行情況，例如取消請求、緊急升級或收到的更新。事件子流程可以是中斷型或非中斷型。
範例：
主要流程：履行訂單
事件子流程：
取消請求 → 取消履行 → 退款給客戶
3.4 活動標記
活動可能包含小型標記，用以提供有關其行為方式的資訊。
迴圈標記
迴圈標記表示活動會重複執行，直到滿足某個條件為止。
範例：
審核文件
↻
用於以下類型的活動：
-
審核直到獲得批准
-
嘗試配送直到成功
-
聯繫客戶直到聯繫上為止
並行多實例標記
這表示同一活動的多個實例同時運行。
範例：
取得三個批准
該活動可由多位審核人同時執行。
順序多實例標記
這表示多個實例依次運行。
範例：
一次審核一個項目
補償標記
此標記用於識別用於補償先前已完成工作的活動。
範例：
退還客戶款項
臨時標記
臨時子流程以類似波浪線的標記表示。它表示子流程內部的活動可以以靈活或鬆散的結構順序執行，而非遵循單一固定序列。
4. 網關：決策、分支與合併
一個網關用於控制流程分支或匯合的方式。網關以菱形繪製。
網關通常不是一個任務。它本身不會執行決策工作。相反，它代表決策、條件或事件評估後，流程如何被控制。
例如：
審核申請 → 請問申請是否完整？
審核活動會收集或評估資訊。隨後，網關根據結果引導流程。
網關可執行：
-
將一條路徑拆分成多條路徑
-
將多條路徑合併為一條
-
同步並行工作
-
等待一個或多個事件
-
根據條件或規則引導工作
4.1 專用閘道：XOR
一個專用閘道會選擇恰好一條輸出路徑。
通常以包含「X」的菱形表示，但在某些圖表中，標記可能會被省略。
範例：
┌── 已批准 → 建立帳戶
檢查申請 ─◇
└── 已拒絕 → 發送拒絕通知
僅會遵循一條路徑。
常見用途：
-
如果付款獲得批准，則繼續；否則拒絕
-
如果客戶符合資格，則提供折扣
-
如果請求已完成，則處理；否則退回
輸出路徑通常應具有明確的條件或標籤：
-
已批准
-
已拒絕
-
已完成
-
未完成
-
金額 > 10,000美元
-
金額 ≤ 10,000美元
專用合併
獨佔閘門也可以將多條替代路徑合併回一條路徑。它不會等待所有路徑，因為僅應選擇其中一條替代路徑。
預設流程
當指定的任何條件都不成立時，可以使用預設路徑。
例如：
已批准
已拒絕
預設 → 手動審核
預設路徑對於意外或未分類的情況很有用。
4.2 並行閘門：AND
一個 並行閘門將流程拆分為多條並行運行的路徑。
它以包含加號的菱形表示。
範例：
┌── 計算發票 ──┐
訂單已批准 ─◇ ◇── 發貨
└── 預留庫存 ┘
兩項活動同時開始，流程稍後可能需要等待兩者都完成。
並行拆分
並行拆分會啟動所有出站路徑。
當所有活動都必須發生，而不論條件如何時，請使用它。
範例：
-
發送確認訊息並更新庫存
-
通知財務部門並通知運營部門
-
執行安全檢查和欺詐檢查
並行匯合
並行匯合會等待所有傳入路徑完成後才繼續。
這有時稱為同步。
準備發票 ──┐
◇── 履行訂單
保留庫存 ┘
如果有一個傳入分支延遲，匯合將等待它。
4.3 包含網關：或
一個包含網關根據哪些條件為真，選擇一個或多個傳出路徑。
它以一個包含圓形的菱形表示。
範例：
客戶符合以下條件：
- 標準折扣
- 忠誠度折扣
- 推廣折扣
如果多個條件同時滿足，則可選擇多於一個與折扣相關的操作。
當以下情況時使用包含網關：
-
一個或多個條件可能為真
-
多個路徑可以同時運行
-
所有選定路徑完成後，流程應繼續
與排他性網關不同，包含網關不一定只選擇一條路徑。與並行網關不同，它也不一定選擇所有路徑。
4.4 事件驅動網關
一個基於事件的閘道根據最先發生的事件來引導流程。
通常後面會跟著捕獲的中間事件或接收任務。
範例：
發送報價 → 基於事件的閘道
├── 收到訊息 → 處理接受
└── 定時器到期 → 發送提醒
只有最先發生的事件會決定路徑。
當流程等待外部行為而非評估已知的業務條件時，應使用基於事件的閘道。例如，流程可能等待客戶回應或逾時。
基於事件的閘道與排他性閘道
| 問題 | 排他性閘道 | 基於事件的閘道 |
|---|---|---|
| 什麼決定路徑？ | 一個條件或業務規則 | 最先發生的事件 |
| 常見問題 | 「請求是否已批准？」 | 「哪個事件最先發生？」 |
| 常見的後續元素 | 活動或序列流 | 捕獲事件或接收任務 |
| 決策來源 | 資料或邏輯 | 外部事件 |
4.5 複雜網關
一個 複雜網關處理無法透過標準網關類型明確表達的進階路由邏輯。
範例包括：
-
在收到三個核准中的至少兩個後繼續
-
根據複雜的條件組合選擇路徑
-
根據自訂規則同步選定的路徑
應謹慎使用複雜網關。在許多情況下，使用多個較簡單的網關或明確命名的業務規則任務會更容易理解與維護。
4.6 事件驅動網關變體
BPMN 也支援事件驅動網關的變體，包括：
-
排他性事件驅動網關
-
平行事件驅動網關
-
啟動型事件驅動網關
平行事件驅動網關可能需要等待多個事件條件，而排他性事件驅動網關則根據第一個發生的事件繼續執行。正確的變體取決於流程是等待單一事件還是多個事件的組合。
5. 流程物件如何協同運作
BPMN圖表的含義來自於事件、活動、網關和序列流之間的關係。
考慮一個訂單流程：
開始
↓
接收訂單
↓
檢查庫存
↓
商品是否可取得？
├── 是 → 包裝訂單 → 發貨訂單 → 結束
└── 否 → 通知客戶 → 結束
此範例包含：
-
一個開始事件用來啟動流程
-
用於接收、檢查、包裝、發貨和通知的活動
-
一個排他性網關用來選擇一條路徑
-
兩個結束事件或代表不同結果的結束路徑
更進階的版本可能是：
開始
↓
接收訂單
↓
檢查庫存
↓
商品是否可取得？
├── 否 → 通知客戶 → 結束
└── 是 → 並行網關
├── 預留庫存
├── 製作發票
└── 檢查詐欺
↓
並行匯合
↓
發貨訂單
↓
結束
在此：
-
排他性網關決定履行是否可以繼續。
-
並行網關啟動三個活動。
-
並行匯合會等待所有三個活動完成。
-
只有在同步完成後，才會開始運輸。
6. 事件、活動與網關：快速比較
| 元素 | 關鍵問題 | 範例 |
|---|---|---|
| 事件 | 發生了什麼事，或將會發生什麼事？ | 收到付款 |
| 活動 | 執行了什麼工作？ | 驗證付款 |
| 網關 | 流程應走哪條路徑？ | 付款是否有效？ |
一個有用的規則是：
-
事件發生
-
活動被執行
-
網關控制路徑
如果你不確定該使用哪個符號，請問：
-
這是否是一種不被視為工作的發生事件？使用一個事件.
-
是否有人或某物正在執行動作？使用一個活動.
-
流程是否正在分叉、合併，或等待路由條件？使用一個網關.
7. 正確連接流程物件
流程物件透過不同類型的線條連接。使用錯誤的連接器可能會使圖表產生誤導。
7.1 串列流程
一個串列流程是一條帶箭頭的實線，用來顯示同一流程中流程物件的執行順序。
活動 A → 活動 B
使用串列流程來連接：
-
事件至活動
-
活動至網關
-
網關至活動
-
活動至結束事件
序列流通常不應跨越不同泳道之間的邊界。
7.2 消息流
一個 消息流是一條帶有開放箭頭的虛線，用來表示不同參與者或泳道之間的通信。
範例：
-
客戶將訂單發送給賣方
-
賣方將確認訊息發送給客戶
-
銀行將付款結果發送給商家
使用消息流來表示通信，而非顯示內部流程順序。
7.3 關聯
一個 關聯是一條點線，用來將實體、註解或資料表示與流程物件連接。
範例：
-
將文件附加到任務
-
將文字註解連結到活動
-
顯示任務使用了資料物件
連接物件的三種主要類型是序列流、消息流和關聯。
8. 泳道與泳道
雖然池和泳道不是流程對象，但它們提供了理解每個活動由誰執行的重要背景。
池
池代表流程中的參與者。
範例：
-
客戶
-
供應商
-
銀行
-
公司
-
政府機構
-
外部系統
池可以包含整個流程，也可以以不顯示內部細節的黑箱參與者形式呈現。
泳道
泳道根據責任、角色、部門、系統或位置來劃分池。
範例：
-
客戶服務
-
財務
-
倉庫
-
經理
-
付款系統
泳道有助於回答以下問題：
誰應該為此活動負責？
它們還能揭示交接、延遲、重複工作和權責不明的情況。
9. 數據物件及其他支援元素
數據物件不是流程物件，但它們能提供有關活動所使用、創建或更改之資訊的有用背景。
範例：
-
申請表
-
發票
-
採購單
-
客戶記錄
-
核准文件
-
運送標籤
數據物件可能以如下方式與活動相連：
申請表 → 審核申請
數據物件標示相關資訊，但不一定代表流程所處理的每一筆資料。
其他支援元素包括：
-
資料儲存：資料儲存的持久位置
-
文字註解：說明性註解
-
群組：相關元素的視覺組織
-
關聯：支援元素與流程物件之間的連結
10. 建立流程模型的逐步方法
步驟 1：定義流程範圍
決定流程的起點與終點。
例如：
從：客戶提交訂單
至：訂單已出貨或被拒絕
避免在一個圖表中建模整個組織。
步驟 2：識別參與者
列出參與的個人、部門、系統或組織。
範例：
-
客戶
-
銷售團隊
-
財務部門
-
倉庫
-
付款網關
這些可能成為池或泳道。
步驟 3：識別啟動觸發條件
詢問：
什麼導致這個流程開始？
使用適當的開始事件：
-
訊息
-
計時器
-
條件觸發
-
信號
-
無
步驟 4：列出主要活動
使用動詞-對象格式撰寫每一項活動：
-
接收訂單
-
驗證訂單
-
計算總額
-
批准付款
-
發送訂單
在此階段，不必擔心每一種例外情況。
步驟 5：加入決策
尋找類似以下的問題：
-
訂單是否已完成？
-
付款是否已批准？
-
庫存是否可用？
-
客戶是否符合資格？
-
截止日期是否已過？
使用網關來表示答案如何影響流程。
步驟 6：新增平行工作
識別可以同時進行的活動。
例如：
-
更新庫存
-
發送確認
-
建立發票
當所有分支都必須完成或同步時，使用平行網關。
步驟 7：新增中間事件與邊界事件
詢問在工作進行期間可能發生什麼情況：
-
該活動是否有截止期限？
-
是否可以取消？
-
是否可能發生錯誤？
-
外部訊息是否可能到達？
-
如果過程耗時過久，是否應升級處理？
步驟 8：新增結束事件
識別所有有意義的結果：
-
已完成
-
拒絕
-
取消
-
失敗
-
升級
-
補償
步驟 9：新增資料與註解
僅在能提升理解時，才包含文件、系統、筆記與商業規則。
步驟 10：檢視圖示
確認以下事項：
-
每個流程路徑都有一個明確的起點
-
每條路徑最終都會結束
-
網關條件應清晰易懂
-
活動應有明確的負責人
-
序列流程應顯示實際順序
-
訊息流程僅在參與者之間使用
-
沒有網關被用作任務
-
圖示未因不必要的細節而過於複雜
11. 常見的 BPMN 建模錯誤
錯誤 1：將網關用作決策活動
網關應負責流程導向，而非執行分析。
弱模型：
◇ 檢查信用分數
較好模型：
檢查信用分數 → 信用是否批准？
此活動執行檢查。網關根據結果進行路由。
錯誤 2：在獨立的泳道之間使用序列流
序列流代表內部流程順序。獨立參與者之間的通信應使用訊息流。
錯誤概念：
客戶泳道 ── 實線序列流 ── 銷售者泳道
較好概念：
客戶泳道 ── 虛線訊息流 ── 銷售者泳道
錯誤 3：未標示網關路徑
未標示的網關會造成歧義。
而非：
◇ → 路徑 A
→ 路徑 B
應使用：
◇
├── 已批准
└── 已拒絕
錯誤 4：使用互斥網關處理並行工作
若所有活動都必須執行，則不應使用互斥網關。
錯誤：
◇ ├── 發送確認
└── 更新庫存
這表示只有一條路徑被選中。
如果兩個活動都必須發生，請使用並行網關：
+ ├── 發送確認
└── 更新庫存
錯誤 5：為條件性工作使用並行網關
並行網關會啟動所有出站路徑。如果只有部分路徑需要執行，請使用互斥或包含網關。
錯誤 6：對每個微小動作進行建模
如果將每個點擊、欄位輸入和內部系統動作都包含在內，圖表可能會變得難以閱讀。
根據您的受眾，選擇合適的建模層級：
-
高階主管需要主要階段
-
流程負責人需要責任與決策
-
開發人員可能需要實作層級的細節
-
審計人員可能需要控制措施與證據
錯誤 7：創建無法繼續的路徑
每個序列流路徑最終都應達到適當的結束事件，或明確定義的子流程邊界。
錯誤 8：不必要地混合業務邏輯與技術實作
業務流程圖應首先說明流程。技術細節僅在對目標受眾有幫助時才應包含。
12. 實用的命名規範
一致的命名使圖表更易閱讀。
事件
以結果、發生或條件命名事件：
-
訂單已收到
-
付款已確認
-
截止日期已達
-
客戶已取消
-
發生錯誤
活動
使用：
動詞 + 物件
範例：
-
審查合約
-
批准請求
-
更新帳戶
-
發送通知
網關
網關通常在與問題關聯時最為清晰：
-
申請是否已完成？
-
付款是否已批准？
-
庫存是否可用？
-
截止日期是否已過？
外出路徑應包含答案：
-
是 / 否
-
批准 / 拒絕
-
可用 / 不可用
結束事件
根據結果命名結束事件：
-
訂單完成
-
請求被拒絕
-
付款失敗
-
案件取消
13. 選擇正確的閘門
使用此決策指南：
| 建模需求 | 應使用的閘門 |
|---|---|
| 根據條件選擇恰好一條路徑 | 獨佔閘門 |
| 啟動每條外出路徑 | 並行閘門 |
| 根據條件選擇一條或多條路徑 | 包含閘門 |
| 遵循第一個發生事件的路徑 | 基於事件的網關 |
| 應用高度專業化的路由規則 | 複雜網關 |
一個快速的腦力測試：
-
一條路徑？ 排他
-
所有路徑？ 並行
-
某些路徑？ 包含
-
第一個事件？ 基於事件
-
非一般的自訂邏輯？ 複雜
14. 完整範例：客戶退款流程
考慮一個客戶退款流程。
開始：收到退款請求
↓
審核退款請求
↓
退款請求是否符合資格？
├── 否
│ ↓
│ 發送拒絕通知
│ ↓
│ 結束：退款被拒絕
│
└── 是
↓
準予退款
↓
並行網關
├── 發放退款
└── 更新客戶帳戶
↓
並行匯合
↓
發送退款確認
↓
結束：退款完成
此模型示範：
-
訊息啟動事件
-
使用者或手動活動
-
獨佔閘道
-
拒絕路徑
-
平行分割
-
平行合併
-
確認活動
-
不同的結束結果
如果退費服務可能失敗，請在「退費」上新增一個邊界錯誤事件發放退費:
發放退費
│
└── 錯誤 → 建立手動審核案件
如果退費必須在五個營業日內完成，請新增一個邊界計時器事件：
發放退費
│
└── 5天逾時 → 升級退費
15. 精簡的BPMN符號速查表
| 符號類別 | 含義 | 典型用途 |
|---|---|---|
| 細圓圈 | 開始事件 | 開始一個流程 |
| 雙圓形 | 中間事件 | 等待、發送、接收或回應 |
| 粗線圓形 | 結束事件 | 完成流程路徑 |
| 圓角矩形 | 任務或活動 | 執行工作 |
| 帶加號的圓角矩形 | 收縮的子流程 | 分組詳細工作 |
| 帶X的菱形 | 獨佔閘道 | 選擇一條路徑 |
| 帶加號的菱形 | 平行閘道 | 執行所有路徑 |
| 帶圓形的菱形 | 包含閘道 | 執行一個或多個路徑 |
| 帶有事件標記的菱形 | 基於事件的網關 | 遵循第一個事件 |
| 實線箭頭 | 序列流 | 顯示內部順序 |
| 虛線箭頭 | 訊息流 | 顯示通訊 |
| 點線連接器 | 關聯 | 連結註解或資料 |
| 池 | 參與者 | 代表一個組織或流程 |
| 泳道 | 角色或職責 | 分配所有權 |
| 文件/資料形狀 | 資料物件 | 顯示所使用或產生的資訊 |
16. 最終建模原則
最有效的BPMN圖表遵循幾項基本原則：
-
使用事件來表示發生的事物。
-
使用活動來表示人員或系統執行的工作。
-
使用網關來控制或同步路徑。
-
使用序列流來表示內部流程順序。
-
使用訊息流來表示參與者之間的溝通。
-
清楚標示決策與外出條件。
-
使用子流程來控制複雜性。
-
使用池和泳道來顯示責任。
-
使用邊界事件來表示逾時、錯誤與中斷。
-
根據受眾的層級進行建模。
-
為每條有意義的路徑設定明確的結果。
-
優先選擇簡單易懂的圖表，而非過於複雜的圖表。
當這三個核心概念變得熟悉後——事件發生、活動被執行，以及網關控制流程——大多數BPMN圖表就會變得更容易閱讀與建立。