BPMN 與流程圖：初學者何時及為何使用 BPMN

流程圖與 BPMN 圖表均顯示工作如何從一個步驟推進到另一個步驟。主要差異在於目的與精確度:

• 一個流程圖是用於展示邏輯、步驟與決策的通用圖表。

• BPMN，即業務流程建模與標記法，是一種標準化語言，專門用於建模業務流程、職責、事件、訊息、資料與自動化。

流程圖通常是解釋簡單程序最快的方式。當流程涉及多人、部門、組織、例外情況、截止期限或軟體系統時，BPMN 則更具實用性。

BPMN 由物件管理組（Object Management Group）維護為正式規範。其標記法設計為業務利害關係人可理解，同時保持足夠的精確度以支援技術實現。目前廣泛使用的正式規範版本為 BPMN 2.0.2。

1. 什麼是流程圖？

流程圖是步驟序列的視覺化呈現。它使用由箭頭連接的簡單圖形，展示任務或決策如何推進。

典型流程圖包含：

• 橢圓形：開始或結束

• 矩形：處理或活動

• 菱形：決策

• 箭頭：流程方向

• 平行四邊形：輸入或輸出

• 文件形狀：文件或報告

例如，一個基本的費用報銷流程圖可能如下所示：

開始
  ↓
員工提交費用報銷單
  ↓
經理審閱報銷單
  ↓
是否核准？
 ├── 否 → 將報銷單退回給員工
 └── 是 → 財務部門發放款項
  ↓
結束

流程圖容易建立與理解，因為它們使用數量有限的熟悉符號。它們適用於：

• 解釋簡單程序

• 記錄演算法

• 描述故障排除步驟

• 繪製個人或部門的工作流程

• 培訓員工

• 展示基本決策序列

主要限制在於傳統流程圖未必能清楚呈現誰執行每項任務, 不同組織如何溝通，或當事件中斷正常流程時會發生什麼事.

2. 什麼是 BPMN？

BPMN 代表業務流程模型與標記法。它是一種用於以一致方式描述業務流程的標準化標記法。

BPMN 圖表可表示：

• 活動與任務

• 開始、中間與結束事件

• 決策與分支邏輯

• 平行工作

• 參與者與職責

• 部門或組織之間的溝通

• 訊息

• 資料輸入與輸出

• 計時器、錯誤、取消與升級

• 可重用的子流程

• 人工與自動化活動

BPMN 基於流程圖概念，但為業務操作增添了更豐富的詞彙。其核心類別包括流程物件、連接物件、泳道與附註物件。

簡化的 BPMN 流程可描述如下：

客戶提交訂單
        ↓
銷售系統記錄訂單
        ↓
倉庫檢查庫存
        ↓
商品是否可用？
 ├── 否 → 通知客戶
 └── 是 → 揀貨並打包訂單
                 ↓
           物流供應商送達訂單

在實際的 BPMN 圖中，每個參與者可以出現在單獨的池或泳道中，它們之間的溝通可以用訊息流程來表示。

3. BPMN 與流程圖一覽

特性	流程圖	BPMN
主要目的	顯示一般邏輯或順序	模擬業務流程
標準化	通常非正式或依賴特定工具	正式國際建模記號
學習曲線	低	中等
符號數量	少量集合	較大且專業的詞彙
角色與職責	通常有限	以池和泳道明確表示
跨組織溝通	難以精確顯示	以訊息流程表示
例外與中斷	通常簡化	事件可表示計時器、錯誤、訊息與升級
平行活動	可能但通常不明確	以平行閘道支援
自動化支援	有限	可詳細到足以支援實作
最佳用途	簡單程序與邏輯	複雜、協作且可重複的流程
典型受眾	一般使用者、學生、團隊	分析師、流程負責人、開發人員、經理
詳細程度	低至中等	中等至非常高

4. 核心差異：一般邏輯與業務流程語義

最重要的區別在於，流程圖主要回答：

「接下來會發生什麼？」

BPMN 可以回答幾個額外問題：

• 誰執行每項活動？

• 涉及哪個部門或組織？

• 互動是內部還是外部？

• 下一步是由訊息、計時器、錯誤或條件觸發嗎？

• 活動可以並行執行嗎？

• 需要哪些資料？

• 如果流程失敗會發生什麼？

• 哪些任務由人員、系統或規則執行？

• 此流程是否可以自動化或監控？

例如，流程圖可能會說：

審查申請 → 核准申請 → 發送確認

BPMN 模型可以區分：

• 客戶提交申請。

• 客服團隊進行驗證。

• 自動化系統會檢查信用資訊。

• 經理會核准超過特定金額的申請。

• 計時器會在三個工作天後觸發提醒。

• 會向客戶發送訊息。

• 錯誤路徑會處理文件遺漏的情況。

流程圖傳達概要，BPMN 則傳達運作結構。

5. 初學者需要的主要 BPMN 元素

BPMN 包含許多符號，但初學者一開始只需掌握一小套核心符號。

事件

事件代表發生的事情，而非某人執行的動作。

它們以圓形繪製。

常見類型包括：

• 開始事件：啟動一個流程

• 中間事件：發生在流程進行中

• 結束事件：完成一個流程

• 訊息事件：收到或發送訊息

• 計時器事件：涉及截止時間或排定時間

• 錯誤事件：發生錯誤

• 升級事件：某事項需要更高層級的關注

範例：

• 客戶下訂單。

• 付款截止時間到期。

• 收到電子郵件。

• 發生系統錯誤。

活動

活動代表正在執行的工作。它們以圓角矩形繪製。

它們可能是：

• 任務：個別工作單位

• 子流程：相關活動的群組

• 使用者任務：由人員透過系統完成的工作

• 服務任務：由軟體自動執行的工作

• 手動任務：無需系統協助即可執行的工作

• 業務規則任務：由業務規則或決策服務決定的工作

對於初學者而言，最重要的概念很簡單：

事件發生；活動被執行。

閘道

閘道控制流程如何分割或合併。它們以菱形繪製。

常見的閘道類型包括：

• 排他性閘道：僅選擇一條路徑

• 平行閘道：多條路徑同時發生

• 包容性閘道：可選擇一條或多條路徑

• 基於事件的閘道：下一條路徑取決於哪一個事件先發生

排他性決策範例：

已收到款項嗎？
 ├── 是 → 出貨訂單
 └── 否 → 發送付款提醒

並行工作範例：

訂單已核准
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
打包訂單      準備發票      通知客戶
 │               │                │
 └───────────────┴────────────────┘
      ↓
訂單已準備好可發貨

序列流程

實線箭頭顯示同一流程中活動、事件和閘門發生的順序。

任務 A → 任務 B → 任務 C

訊息流程

虛線箭頭代表不同參與者或泳道池之間的通訊。

例如：

客戶 ──訊息──> 公司
公司 ──確認──> 客戶

訊息流程與序列流程不同：

• 序列流程：顯示流程內工作的順序

• 訊息流程：顯示參與者之間的通訊

泳道池與泳道

泳道按參與者或職責組織工作。

• 一個「泳道池」通常代表一個參與者、組織、業務實體或獨立流程。

• 一個「泳道」將泳道池劃分為角色、團隊、部門或系統。

範例：

客戶泳道：     提交訂單 ─────────────── 接收確認
                         │                              ↑
銷售泳道：              審閱訂單 ─────── 發送確認

泳道池與泳道回答流程中最重要問題之一：

誰負責此步驟？

資料物件與註解

資料物件顯示活動所使用或產生的資訊。

範例：

• 申請表

• 發票

• 合約

• 客戶記錄

• 運送標籤

註解會加入解釋性文字，但不會改變流程邏輯。

6. 何時流程圖是較佳的選擇

當流程簡單、線性，或主要涉及決策時，請使用流程圖。

在以下情況下，流程圖通常已足夠：

• 只有一位主要參與者

• 流程僅包含少數步驟

• 無需強調職責

• 與外部單位之間沒有複雜的互動

• 該圖表僅用於快速說明

• 該流程正以非正式方式進行探討

• 您正在記錄演算法或除錯程序

• 您的受眾不熟悉 BPMN

例如，「如何重設密碼」可能以簡單流程圖表示更佳：

開始
  ↓
輸入使用者名稱
  ↓
找到帳號？
 ├── 否 → 顯示錯誤
 └── 是 → 發送重設密碼電子郵件
                ↓
          使用者建立密碼
                ↓
               結束

除非目的是建立完整服務作業的模型（包括身分驗證、通知、系統任務、升級處理及稽核記錄），否則使用 BPMN 處理此流程可能會增加不必要的複雜度。

7. 何時 BPMN 是較佳的選擇

當您需要建立真實業務流程的模型，而不僅僅是描述序列時，請使用 BPMN。

當流程具備以下特徵時，BPMN 特別有用：

• 多個部門

• 多個角色或參與者

• 客戶、供應商、監管機構或合作夥伴

• 團隊之間的交接

• 平行活動

• 外部訊息

• 計時器或期限

• 錯誤或例外處理

• 核准層級

• 自動化系統任務

• 合規要求

• 重複的流程改進工作

• 工作流程自動化的一項未來目標

典型的 BPMN 使用案例包括：

• 採購訂單核准

• 貸款申請處理

• 保險理賠

• 員工入職

• 客戶支援升級

• 發票處理

• 產品退貨

• 醫療轉診

• 合約審查

• 出貨履行

• 監管報告

• 軟體部署工作流程

一項有用的法則是：

若流程跨越邊界（例如在人與人、團隊與團隊、系統與系統或組織與組織之間），通常值得考慮使用 BPMN。

8. 為何使用 BPMN？

共用語言

不同群組往往以不同方式描述同一流程。業務經理可能談論核准，開發人員可能談論服務，而員工則談論日常任務。

BPMN 提供了一種共用的視覺語言，可協助這些群組討論同一流程。其設計目標是讓業務利害關係人能夠使用，同時又足夠精確，可轉換為軟體流程元件。

明確的責任歸屬

泳道使責任可見。

與其顯示：

審查申請 → 核准申請 → 建立帳戶

BPMN 可以顯示：

• 客戶提交申請

• 客服驗證資訊

• 信用團隊進行評估

• 經理核准例外情況

• 資訊系統建立帳戶

這可能揭示重複工作、不清晰的責任歸屬以及不必要的交接。

更佳的例外分析

許多實際流程並未遵循理想路徑。BPMN 使建模更為容易：「

• 資訊缺失

• 遭駁回的申請

• 逾期期限

• 付款失敗

• 系統錯誤

• 取消作業

• 客戶申訴升級

• 補償或矯正措施

流程圖可以顯示例外情況，但 BPMN 提供專門的事件類型與規範，以更清晰地呈現它們。

自動化支援

BPMN 模型可包含足夠的細節以指導工作流程的實施。並非所有 BPMN 圖表皆可執行，但若模型未來可能用於設定或設計自動化流程，則 BPMN 比基本流程圖更為合適。

例如，流程設計者可能區分以下項目：「

• 由員工執行的任務

• 由自動化服務執行的任務

• 由業務規則評估的決策

• 從其他系統接收的訊息

• 觸發動作的計時器

更佳的流程改善

BPMN 圖表可協助識別：「

• 瓶頸

• 冗長的核准鏈

• 重複的資料輸入

• 不必要的審查

• 適合自動化的手動任務

• 缺少異常路徑

• 過度交接

• 所有權不明確

• 由外部方造成的延遲

這使得 BPMN 不僅對記錄流程有價值，也對分析和重新設計流程有價值。

9. BPMN 的缺點

BPMN 功能強大，但並非總是正確選擇。

學習曲線較陡峭

流程圖通常可以立即理解。BPMN 則要求用戶學習以下區別：

• 順序流與訊息流

• 事件與活動

• 池與泳道

• 排他閘與平行閘

• 中斷事件與非中斷事件

• 捕獲事件與拋出事件

圖表可能變得雜亂

大型 BPMN 圖表可能包含數十個符號和交叉線。設計不良的模型可能比簡單的流程圖更難理解。

精確性可能產生錯誤的信心

使用 BPMN 符號並不會自動使流程模型準確。模型仍依賴於流程所有者和領域專家提供的正確資訊。

並非所有受眾都需要完整細節

高層管理者可能希望獲得高階流程概覽，而工作流開發者可能需要詳細的任務和異常資訊。一張圖表很少能完美同時滿足這兩種目的。

可能被過度使用

五步驟的內部程序不一定需要訊息事件、多個池和嵌套子流程。記號應與問題相匹配。

10. 實用決策指南

使用以下問題在流程圖和 BPMN 之間做出選擇：

1. 涉及多少參與者？

   • 一人或一個團隊：流程圖可能就足夠了。

   • 多個團隊或組織：BPMN 更為適合。

2. 職責是否重要？

   • 如果否，請使用流程圖。

   • 如果是，請在 BPMN 中使用泳道或池。

3. 是否存在外部溝通？

   • 如果否，兩種標記法均可適用。

   • 如果是，BPMN 可區分訊息與內部流程。

4. 是否存在計時器、錯誤或升級機制？

   • 如果否，流程圖可能已足夠。

   • 如果是，BPMN 提供更清晰的建模工具。

5. 該流程是否將被自動化？

   • 如果否，對於簡單流程，流程圖可能已足夠。

   • 如果是，BPMN 通常是更好的基礎。

6. 該流程是否需要作為正式標準重複使用？

   • 如果否，請使用您的受眾能理解的最簡單標記法。

   • 如果是，BPMN 可提供圖形與工具之間更高的一致性。

7. 您的受眾技能水平為何？

   • 一般受眾：從簡單的流程圖或高階 BPMN 開始。

   • 分析師與技術團隊：使用具有適當細節的 BPMN。

11. 適合初學者的 BPMN 建模方法

步驟 1：定義流程邊界

決定流程的起始點與終止點。

例如：

• 起始：客戶提交支援請求

• 終止：客戶收到解決方案

避免試圖一次建模整個組織。

步驟 2：識別參與者

列出涉及的個人、團隊、組織與系統。

範例：

• 客戶

• 支援專員

• 技術支援團隊

• 計費系統

• 服務經理

這些可能成為泳道或流程池。

步驟 3：先撰寫正常流程

記錄不含例外情況的正常流程。

接收請求
  ↓
分類請求
  ↓
調查問題
  ↓
解決問題
  ↓
通知客戶
  ↓
關閉請求

這讓您在增加複雜性之前，擁有清晰的基礎。

步驟 4：新增開始與結束事件

每個完整的 BPMN 流程都應有明確的開始與結束。

範例：

• 開始：收到訊息

• 開始：計時器已觸發

• 開始：客戶提交表單

• 結束：案件已關閉

• 結束：請求遭拒絕

• 結束：付款已完成

步驟 5：將工作分配給參與者

將每個活動放置於適當的泳道中。

例如：

客戶：       提交請求 ───────────── 接收解決方案
支援：                    分類 ─ 調查 ─ 解決
系統：                                      發送通知

步驟 6：新增決策閘道

當僅應遵循單一路徑時，請使用排他性閘道。

問題已解決？
 ├── 否 → 升級處理
 └── 是 → 通知客戶

不要僅因任務名稱中包含問號就使用閘道。僅當流程實際分岔時才使用。

步驟 7：謹慎新增平行工作

當活動確實可以同時發生時，請使用平行閘道。

例如，訂單核准後：

• 保留庫存

• 產生發票

• 通知倉庫

如果一項活動必須在另一項活動之前發生，則不要將它們建模為並行。

步驟 8：新增訊息與資料

當參與者進行溝通時，顯示訊息。

範例：

• 客戶傳送申請

• 供應商傳送出貨通知

• 系統傳送核准電子郵件

當資訊對活動至關重要時，新增資料物件。

步驟 9：新增例外情況

詢問：

• 如果缺少所需資訊怎麼辦？

• 如果客戶未回覆怎麼辦？

• 如果付款失敗怎麼辦？

• 如果期限屆滿怎麼辦？

• 如果系統無法使用怎麼辦？

• 如果員工拒絕申請怎麼辦？

僅建模對理解或改善流程至關重要的例外情況。

步驟 10：與流程負責人檢視圖表

圖表應由執行工作的人員進行檢視。他們可以識別：

• 遺漏的步驟

• 不正確的職責

• 非正式的變通方法

• 未在程序文件中記錄的例外情況

• 延遲與不必要的核准

12. 範例：流程圖版本與 BPMN 版本

簡單流程圖

假設客戶退貨：

開始
  ↓
客戶提出退貨申請
  ↓
退貨是否符合資格？
 ├── 否 → 拒絕申請
 └── 是 → 寄送退貨標籤
                ↓
          收到退貨商品
                ↓
          發出退款
                ↓
               結束

這容易理解，可能足以用於培訓或快速概覽。

BPMN 導向版本

更詳細的 BPMN 模型會區分參與者：

客戶

• 申請退貨

• 包裝產品

• 寄送產品

客戶服務

• 驗證退貨申請

• 批准或拒絕退貨

• 發送退貨指示

倉庫

• 接收產品

• 檢查狀況

財務

• 發放退款

系統

• 發送確認

• 更新庫存

• 記錄退款

該模型亦可表示：

• 來自客戶的訊息

• 退貨期限的計時器

• 基於產品狀況的閘道

• 若未收到商品則產生錯誤

• 並行的庫存與退款活動

• 確認退款的訊息

流程圖說明整體邏輯，BPMN 則說明營運協作。

13. 初學者常見錯誤

錯誤 1：使用所有 BPMN 符號

初學者有時會嘗試使用盡可能多的符號，這會使圖表更難閱讀。

從以下開始：

• 開始與結束事件

• 任務

• 排他式閘道

• 序列流程

• 泳道與池

• 在需要時使用訊息流程

僅在能解決實際建模問題時，才添加進階元素。

錯誤 2：混淆序列流程與訊息流程

序列流程顯示流程內部的進展；訊息流程顯示不同參與者之間的溝通。

切勿僅為了讓線條看起來不同而使用訊息流程。

錯誤 3：錯誤地混用池與泳道

使用泳道來劃分單一參與者內部的職責；當參與者為獨立實體或流程時，請使用獨立的池。

例如：

• 銷售、財務與營運可能是同一公司內的泳道。

• 客戶與供應商可能是獨立的池。

錯誤 4：將每個決策都視為排他式

排他式閘道表示僅選擇一條路徑。若多條路徑可能同時發生，請使用並行閘道；若一條或多條可選路徑可能發生，請考慮使用包容式閘道。

錯誤 5：省略觸發條件

流程應說明其啟動原因。「處理訂單」若未明確顯示觸發條件，則過於模糊，例如觸發條件是否為：

• 客戶訂單

• 排程批次

• 付款確認

• 來自其他系統的訊息

錯誤 6：僅建模理想流程

實際流程包含重做、拒絕、延遲與升級。僅顯示理想路徑的模型可能看似吸引人，但在運作上卻不完整。

錯誤 7：在活動中放入過多文字

任務標籤通常應採用簡潔的動詞 – 名詞格式：

• 審查申請

• 驗證地址

• 核准退款

• 發送確認

避免在任務框內使用長段落。將輔助說明放在註解或文件中。

錯誤 8：建立單一巨型圖表

大型流程應拆分為子流程。高階圖表可能顯示：

接收訂單 → 處理付款 → 履行訂單 → 結案訂單

每個階段均可連結至更詳細的圖表。

14. 可讀圖表的 BPMN 最佳實踐

• 以明確的起始事件開始。

• 以一個或多個有意義的結束狀態結束。

• 將主要流程由左至右或由上至下排列。

• 盡可能保持序列流程線筆直。

• 避免線條交叉。

• 使用一致的任務名稱。

• 將主圖表保持在可讀的詳細程度。

• 僅在責任至關重要時使用泳道。

• 以有意義的問題或條件標記閘道。

• 當含義不明顯時，標記閘道的輸出路徑。

• 使用子流程隱藏不必要的細節。

• 區分正常路徑與異常路徑。

• 將訊息流程保持在適當的池之間。

• 節制使用註解。

• 與執行該流程的人員驗證模型。

• 重新設計流程時，建立獨立的「現狀」與「未來狀態」圖表。

15. 初學者應學習多少 BPMN？

您無需學習完整的 BPMN 規範即可建立實用的圖表。

初學者等級

學習：

• 起始事件

• 結束事件

• 任務

• 序列流程

• 排他閘道

• 平行閘道

• 池

• 泳道

• 訊息流程

• 基本資料物件

這已足以應付許多業務流程圖。

中級

新增：

• 計時器事件

• 訊息事件

• 錯誤事件

• 子流程

• 呼叫活動

• 使用者任務

• 服務任務

• 邊界事件

• 基於事件之閘道

• 補償路徑

進階

研讀：

• 協作圖

• 對話圖

• 非中斷事件

• 事件子流程

• 交易

• 補償

• 多執行個體活動

• 關聯性

• 執行語義

• 特定工具的實作規則

BPMN 支援多種模型類型，包括流程圖、協作圖、編排圖和對話圖。初學者通常應先從一般的流程圖和協作圖開始，再研習更專業的類型。

16. BPMN、流程圖與相關記號

BPMN 並非唯一的建模記號。

• 流程圖：最適合簡單邏輯與程序

• BPMN：最適合業務流程與工作流協作

• UML 活動圖：適用於軟體與系統行為

• DMN：適用於正式業務決策與規則

• CMMN：適用於靈活的、以案例為基礎的工作，其中路徑未完全預先定義

• 價值流圖：適用於分析端到端的價值與浪費

• SIPOC 圖：適用於高階供應商、輸入、流程、輸出、客戶分析

BPMN 可能顯示決策的發生，而專注於決策的記號（如 DMN）則可描述用於做出該決策的規則。這些記號可以互補而非競爭。

17. 一個簡單的經驗法則

選擇一個流程圖當：

您需要以最快速且簡單的方式解釋一系列步驟或決策。

選擇BPMN當：

您需要理解、溝通、分析、改善或自動化涉及職責、事件、系統或組織的業務流程。

您也可以同時使用兩者：

1. 從簡單的流程圖開始，以了解整體流程。

2. 當角色、訊息、例外情況、時間或自動化變得重要時，將其轉換為 BPMN。

3. 為高層主管建立高階 BPMN 圖，並為分析師或開發人員建立詳細版本。

結論

流程圖和 BPMN 並非在所有情況下都是競爭工具。流程圖是一種輕量級的視覺說明；BPMN 則是用於需要更高清晰度、責任歸屬與運作細節之流程的結構化建模語言。

對於初學者而言，最佳方法是從簡單開始：

• 定義流程的邊界。

• 識別參與者。

• 繪製正常路徑。

• 加入決策點。

• 分配責任。

• 僅在必要時才加入訊息、計時器、資料與例外情況。

• 使用子流程以控制複雜度。

如果您的流程短且由單一人員或團隊處理，流程圖可能就足夠了。若流程涉及多個角色、部門、系統、外部單位、期限或自動化，BPMN 通常能提供更清晰且更持久的模型。