BPMN 圖表完整指南：實用業務流程說明（2026）

業務流程的失敗，往往不是因為人員能力不足，而是流程文件不完善、不同團隊對流程的理解各異。BPMN 的存在正是為了解決這個問題——一套業務分析師、開發人員與主管都能讀懂的標準化符號系統。

如果你曾看過帶有圓圈、粗邊框和標有 X 的閘道的流程圖，那你就接觸過 BPMN 了。本指南將解釋這些符號的含義、BPMN 值得投入的時機，以及如何繪製真正能有效溝通的業務流程圖。

什麼是 BPMN？

BPMN 是「業務流程模型與符號」（Business Process Model and Notation）的縮寫。這是由物件管理組織（Object Management Group，OMG）維護的國際標準（ISO/IEC 19510），專門用於建立業務流程模型。現行版本 BPMN 2.0 於 2011 年發布，至今仍是主流標準。

關鍵詞在於符號——BPMN 定義了一套具有精確規則的特定視覺語言，而非一般的流程圖繪製方式。德國顧問所繪製的 BPMN 圖表，對韓國開發人員而言應具有相同的意義。

BPMN 2.0 同時定義了 XML 交換格式，這意味著在某工具中建立的 BPMN 圖表可以匯入另一工具——部分工具甚至能直接執行 BPMN 圖表作為運行中的工作流程。

BPMN 與一般流程圖的比較

大多數流程都以基本流程圖記錄。BPMN 更有結構、表達能力更強。正確的選擇取決於你的受眾和目的。

面向	一般流程圖	BPMN 圖表
標準	無正式標準	ISO/IEC 19510（BPMN 2.0）
學習曲線	極低——廣泛理解	中等——需要學習符號規範
事件類型	僅開始／結束	30+ 種事件類型（計時器、訊息、錯誤）
平行處理	難以表達	內建平行閘道支援
多方參與者	泳道方式較為繁瑣	原生的池與泳道支援
工具可執行	否	是（搭配 BPMS 工具）
最適合	簡單流程、快速文件記錄	複雜跨組織流程、自動化
受眾	任何人	業務分析師、流程工程師

使用一般流程圖的時機：

你需要快速向非技術受眾說明流程
流程屬於單人或單一團隊內部
準確度要求較為非正式
你是在草稿階段，而非為了實作而記錄

使用 BPMN 的時機：

流程跨越多個部門或組織
你正在自動化或在工作流程引擎中實作該流程
法規遵循要求具可稽核的流程文件
你需要與開發人員或 BPM 工具進行精確溝通

BPMN 2.0 核心元素

BPMN 有四大類元素：流程物件、連接物件、泳道和人工製品。

事件

事件代表某件事的發生。以圓圈表示，出現在流程的開始、中間或結束。

  (  )         (  ●  )        (  ×  )
 開始          訊息            終止
  事件          開始            結束

開始事件（細邊框圓圈）觸發流程：

一般開始：流程以手動或按需方式啟動
訊息開始：流程由傳入訊息觸發
計時器開始：流程依排程觸發

中間事件（雙邊框圓圈）在流程中發生：

訊息中間：在流程中間發送或接收訊息
計時器中間：在繼續之前等待特定時間
錯誤中間：捕捉子流程中的錯誤

結束事件（粗邊框圓圈）完成流程：

一般結束：流程正常結束
訊息結束：流程透過傳送訊息結束
終止結束：立即停止流程中的所有活動

活動

活動代表正在執行的工作。以圓角矩形表示。

任務是不可再分解的最小工作單位——一個無法進一步細分的單一步驟：

┌─────────────────────┐
│   審查發票           │
└─────────────────────┘

任務類型以左上角的圖示表示：

使用者任務：由人員執行工作
服務任務：由系統自動執行工作
腳本任務：由腳本或規則引擎執行
手動任務：不借助軟體輔助完成

子流程內部包含嵌套流程：

┌─────────────────────┐
│  處理付款            │
│          [+]        │
└─────────────────────┘

[+] 標記表示折疊的子流程，隱藏了內部細節。展開後可查看內部步驟。

閘道

閘道控制序列流的分岔或合流。以菱形表示。

互斥閘道（XOR）——根據條件只走一條路徑：

       ┌─────────────────┐
       │  查詢餘額        │
       └────────┬────────┘
                ↓
            ◇ XOR ◇
           ╱         ╲
      [足夠]           [不足]
          ↓               ↓
    ┌──────────┐    ┌──────────────┐
    │  批准    │    │  拒絕貸款    │
    └──────────┘    └──────────────┘

平行閘道（AND）——所有路徑同時執行：

            ◇ AND ◇
           ╱   |   ╲
          ↓    ↓    ↓
      傳送  更新  通知
      郵件   DB   團隊

當步驟可以並行執行時使用。配對的關閉閘道會等待所有路徑完成後才繼續。

包容閘道（OR）——根據條件執行一條或多條路徑：

            ◇ OR ◇
           ╱       ╲
    [高優先級]   [任意訂單]
          ↓               ↓
    升級至主管       記錄工單

包容閘道會評估所有條件。任何條件為真時都會建立一條有效路徑。

序列流

序列流是連接池內元素的箭頭，表示活動的順序。

一般流： 實線箭頭
預設流： 源端帶有斜線的箭頭（在沒有其他條件適用時使用）
條件流： 源端帶有菱形的箭頭（只有條件為真時才使用）

池與泳道

池代表參與者——執行流程的組織、系統或角色。泳道將池細分為內部角色或部門。

┌─────────────────────────────────────────────────────────┐
│ 池：訂單履行流程                                          │
│  ┌──────────────────────────────────────────────────┐  │
│  │ 泳道：銷售                                         │  │
│  │  （開始）→ 接收訂單 → 確認庫存                      │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │ 泳道：倉庫                                         │  │
│  │  揀貨 → 包裝 → 出貨                                │  │
│  └──────────────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────────────┐  │
│  │ 泳道：財務                                         │  │
│  │  產生發票 → 收款                                   │  │
│  └──────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

關鍵規則：

一個池 = 一個流程參與者
泳道將參與者細分為角色（不是獨立參與者）
序列流連接同一池內的元素
訊息流連接不同池之間的元素（虛線箭頭）

BPMN 的過度使用情況

BPMN 強大但繁重。預設使用它會增加不必要的摩擦。

以下情況可跳過 BPMN：

你正在為快速團隊討論記錄流程
流程不超過 10 個步驟且只有一個參與者
你的受眾不熟悉 BPMN 符號（可能造成更多困惑而非釐清）
流程仍在探索階段，可能會有重大變化

以下情況必須使用 BPMN：

流程將在工作流程引擎中實作（Camunda、Activiti、jBPM）
多個組織需要正式確認流程責任
法規遵循要求 ISO 標準文件
流程涉及複雜的平行執行路徑
你正在整合系統，需要精確記錄訊息交換

逐步指南：建立 BPMN 圖表

第一步：定義流程範圍

命名流程並設定其邊界：

什麼事件啟動流程？
什麼事件結束它？（不同結果可能有多個結束事件）
哪個參與者擁有該流程？

第二步：識別參與者

列出所有涉及的各方：

哪些角色或部門執行活動？
哪些外部系統發送或接收資訊？
哪些方是外部的（獨立組織）？

每個參與者建立一個池。如果外部方只接收通知，它們以黑箱池形式出現，不含內部細節。

第三步：先繪製主要路徑

在添加例外情況之前，先繪製正常的成功流程：

放置開始事件
按順序添加活動
用序列流連接
添加結束事件

這為你提供了一個可以繼續構建的工作架構。

第四步：添加決策點

識別流程分岔的每一處：

哪些條件決定走哪條路？
路徑是互斥的（XOR）還是可以多條同時觸發（OR）？
步驟可以平行執行嗎（AND）？

放置適當的閘道類型，並為每條出去的流標記條件。

第五步：處理例外情況和錯誤

添加中間錯誤事件和例外路徑：

如果任務失敗會怎樣？
存在哪些超時？
哪些外部事件可以中斷流程？

第六步：在池之間添加訊息流

如果存在多個池，繪製虛線訊息流箭頭，顯示參與者之間傳遞了哪些資訊。

第七步：與利害關係人審查

與實際流程參與者一起瀏覽圖表。詢問：

這是否反映了實際發生的情況，而不只是理想狀態？
活動是否被放置在正確的泳道中？
閘道是否正確代表了決策邏輯？

實際範例：訂單處理

┌─────────────────────────────────────────────────────────────────────────┐
│ 池：電子商務訂單流程                                                       │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ 泳道：客服                                                          │  │
│  │  （開始）→ 接收訂單 → 傳送確認                                       │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ 泳道：庫存                                                          │  │
│  │  查詢庫存 → ◇XOR◇ → [有庫存] → 保留商品                            │  │
│  │                    → [無庫存] → 缺貨通知 → (結束)                  │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ 泳道：付款                                                          │  │
│  │  處理付款 → ◇XOR◇ → [成功] → 確認                                  │  │
│  │                    → [失敗] → 通知客戶 → (結束)                    │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ 泳道：履行                                                          │  │
│  │  揀貨 → 包裝訂單 → 出貨 → [計時器：3天] → (結束)                    │  │
│  └───────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────┘

注意此圖表如何呈現：

多條例外路徑（缺貨、付款失敗）
用於出貨追蹤的計時器事件
清晰的泳道職責與可見的交接

常見的 BPMN 錯誤

閘道使用錯誤。 在步驟實際上是平行執行時放置 XOR 閘道，反之亦然。閘道類型必須與實際執行邏輯相符。

忘記關閉平行閘道。 AND 分岔必須有對應的 AND 合流。如果平行路徑開啟但從未合流，圖表意味著流程永遠不會完成。

將所有內容放在一個池中。 獨立的組織或外部系統應該是獨立的池，而不是泳道。泳道用於一個參與者內部的角色。

過度使用 BPMN 符號。 並非每個圖表都需要中間事件、補償標記和事件子流程。從簡單開始，只在確實反映實際流程行為時才增加複雜性。

混合抽象層級。 一個泳道展示高層次的「處理申請」，而另一個泳道展示 12 個詳細子步驟。保持粒度一致——要麼在同一細節層級展示所有泳道，要麼使用子流程折疊細節。

閘道流上無標籤。 離開閘道的每條序列流（預設流除外）必須有條件標籤。未標記的分支會造成何時執行每條路徑的歧義。

使用 Flowova 建立 BPMN 圖表

BPMN 圖表以手動方式建立時出了名地緩慢——即使在專用工具中，正確使用符號、對齊元素和連接複雜的閘道邏輯也需要時間。

Flowova 的 BPMN 圖表生成器可以讓你用純文字描述業務流程，生成一個可以進一步優化的結構化圖表。這對於從流程描述草擬初始圖表，或將現有文件轉換為視覺形式特別有用。生成後，你可以直接在編輯器中調整閘道類型、添加泳道並連接例外路徑。

結語

BPMN 在精確性至關重要時是正確的工具：多方流程、工作流程自動化和法規遵循文件。對於內部溝通和簡單流程，一般流程圖更快且更容易理解。

當你確實使用 BPMN 時，先從主要路徑開始，正確設定閘道類型，並使你的泳道結構與實際組織邊界相符——而非理想化的組織架構圖。