Posted inAI AI Chatbot BPMN VPasCode

使用 Visual Paradigm 的 BPMN 指南

1. BPMN 是什麼

業務流程模型與標記法（BPMN）是一種標準化的視覺語言，用於描述工作如何在流程中流動。它協助業務利害關係人、分析師和技術團隊使用一致的符號討論相同的工作流程。BPMN 由物件管理組（Object Management Group）維護；BPMN 2.0.2 已發布為 ISO/IEC 19510 標準。

BPMN 圖表不僅僅是流程圖：其符號具有明確的含義，其連接規則區分了流程流向與參與者之間的訊息。一個實用的模型可以記錄當前流程（「現狀」），釐清擬議流程（「未來狀態」），並協助團隊發現延遲、交接、重做或缺失的異常路徑。

BPMN 圖表展示工作流程範例，並附有圖例說明事件、活動、閘道、序列流和訊息流符號。

2. BPMN 核心概念

BPMN 的主要構建塊包括流程物件、連接物件、泳道、資料和工件。

元素 代表內容 典型標記與用途
事件 流程中發生的事情 圓形。開始、中間和結束事件分別標示流程何時開始、何事發生或何條路徑結束。
活動 執行的工作 圓角矩形。任務是單一工作單位；子流程則將更詳細的流程進行分組。
閘道 路由或同步邏輯 菱形。用於做出決策、啟動平行路徑或合併路徑。
序列流程 流程內工作的順序 實線箭頭。連接同一泳道池內的流程元素。
訊息流程 參與者之間的溝通 虛線箭頭。顯示訊息在泳道池之間傳遞；它不代表池內步驟的順序。
泳道池與泳道 參與者或負責方 泳道池代表一個參與者或流程；泳道則將池內的職責進行劃分。
資料物件 / 資料儲存 使用或產生的資訊 顯示文件、記錄或資訊，其存在範圍超越單一活動。
註解 / 群組 額外的解釋性情境 新增註解或視覺化地將元素分組，但不改變流程順序。

事件

事件的輪廓與標記傳達其角色與觸發條件：

  • 起始事件：啟動一條流程路徑。

  • 中間事件：發生於流程執行期間——例如收到訊息或計時器到期。

  • 結束事件：終止一條路徑。不同的結束事件類型可表示不同的結果，例如正常完成或發生錯誤。

  • 邊界事件：附加於活動或子流程，用以顯示可能中斷或影響該活動的事件，例如逾時。

使用「訊息事件」當流程回應通訊時，以及使用「計時器事件」當時間因素是流程規則的一部分時，例如截止期限。

活動

以清晰的「動詞 + 受詞」命名活動，例如「檢查庫存」、「核准付款」或「發送確認」。請使用：

  • 任務表示單一步驟。

  • 子流程表示某步驟具有足夠的細節，可獨立建模。

  • 呼叫活動表示重複使用全域定義的流程（若您的建模方法支援此功能）。

常見的任務標記可用於指定工作類型，例如由使用者執行、手動或自動化工作。僅在有助於讀者理解或實作時，才添加此類細節。

閘道

根據流程邏輯選擇閘道，而不僅是基於您想繪製的形狀：

  • 排他性（XOR）：選擇其中一條 outgoing 路徑。範例：「有庫存嗎？」→ 是或否。

  • 並行（AND）：啟動所有 outgoing 路徑；對應的合併點可等待所有必要路徑完成。

  • 包容性（OR）：根據條件選擇一條或多條 outgoing 路徑。

  • 基於事件：下一條路徑由首先發生的事件決定，例如付款回應或超時。

為 outgoing 決策流程標註條件，例如：是 / 否或核准 / 拒絕。當閘道將流程拆分時，請使合併邏輯清晰。排他性合併將替代路徑重新匯合；並行合併則同步原本並行啟動的路徑。

連接物件與泳道池

一個序列流程顯示流程順序，通常保留在同一個泳道池內。一個訊息流程顯示不同泳道池之間的溝通，例如客戶向公司下達訂單。請勿使用訊息流程來顯示下一個內部任務，也請勿使用序列流程來描繪不同參與者之間的溝通。

泳道池可代表獨立參與者，例如客戶、公司與付款服務提供者。泳道池內的泳道顯示角色或部門。請確保責任邊界有意義：泳道應明確說明誰負責執行工作，而非僅用於裝飾圖表。

3. 實用的建模工作流程

  1. 設定範圍。說明流程的觸發條件、結果與邊界。例如：「從接收訂單到確認出貨。」

  2. 識別參與者與角色。決定哪些參與者需要獨立的泳道池，以及哪些責任應歸屬於泳道。

  3. 撰寫正常路徑。在加入閘道與異常路徑之前，依序列出一般步驟。

  4. 加入事件與決策。顯示有意義的觸發條件、結果、業務規則和替代路徑。

  5. 新增交接點和資料。標註參與者之間的溝通，以及在有助於理解時標註所需或產生的資訊。

  6. 檢查完整性。追蹤每一條從開始到結束的路徑。確認閘道具有可理解的條件，且例外路徑不會以模糊的方式消失。

  7. 與流程使用者進行審查。與執行或接收工作的人員驗證模型。當模型與實際做法不符時，請進行修正。

  8. 保持圖表的可讀性。使用一致的命名，盡量減少線條交錯，並在需要時將詳細的子流程移至單獨的圖表中。

從能回答業務問題的模型開始。一次性加入所有 BPMN 符號或實作細節，往往會使圖表更難審查。

4. 範例：線上訂單履行

範圍：從客戶下達訂單開始，到確認出貨為止。此範例著重於公司的流程，並使用獨立的客戶泳道來顯示 incoming 訂單與 outgoing 確認。

流程敘述

  1. 客戶提交訂單。

  2. 公司收到訂單並檢查庫存。

  3. 若商品無貨，公司將通知客戶並終止該訂單路徑。

  4. 若商品有貨，公司將處理付款。

  5. 若付款遭拒，公司將通知客戶並終止該路徑。

  6. 若付款獲准，倉庫將揀貨並打包訂單。

  7. 公司將包裹交給運送業者，並發送出貨確認。

文字圖表

 

Visual Paradigm 中的 BPMN 訂單履行圖表，展示客戶與公司泳道池，包含序列流、閘道和訊息流。

客戶泳道：
(開始) → 提交訂單 ──訊息──▶

公司泳道：
(訊息開始：收到訂單)
  → 檢查庫存
  → XOR：有庫存嗎？
      否  → 通知客戶：無貨 → (結束)
      是 → 處理付款
             → XOR：付款已核准？
                 否  → 通知客戶：付款遭拒 → (結束)
                 是 → 揀貨並打包訂單
                         → 將包裹交給運送業者
                         → 發送出貨確認 ──訊息──▶ 客戶
                         → (結束)

BPMN 圖表展示客戶訂單流程，包含公司庫存檢查、付款核准和出貨確認步驟。

BPMN 自訂 PlantUML 程式碼（僅 VPasCode 編輯器支援）

PlantUML


在 VPasCode 中編輯 PlantUML
PlantUML


在 VPasCode 中編輯 PlantUML
PlantUML Edit PlantUML in VPasCode 
@startuml
title 訂單履行業務流程圖
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|客戶|
start
:<<SendTask>>
提交訂單;

|#E8F5E9|公司|
:<<ReceiveTask>>
收到訂單;
:<<UserTask>>
檢查庫存;
if (有庫存？) then (是)
  :<<ServiceTask>>
  處理付款;
  if (付款已核准？) then (是)
    :<<ManualTask>>
    揀貨並打包訂單;
    :<<SendTask>>
    將包裹交給運送業者;
    :<<SendTask>>
    發送出貨確認;
  else (否)
    :<<SendTask>>
    通知客戶：付款遭拒;
  endif
else (否)
  :<<SendTask>>
  通知客戶：無貨;
endif
stop
@enduml
Edit PlantUML in VPasCode



在 VPasCode 中編輯 PlantUML


在 VPasCode 中編輯 PlantUML

使用序列流程用於公司的內部步驟，以及訊息流程在客戶池與公司池之間。為每個 XOR 閘門的輸出流程標註其條件。在 Visual Paradigm 中，「有庫存嗎？」與「付款已核准？」等問題可作為閘門標籤，而輸出箭頭則標註「是」與「否」。

可能的擴充功能：若業務有付款期限，可在付款處理中加入計時器邊界事件；為運送交接失敗新增例外路徑；或若揀貨與包裝需要獨立詳細工作流程，則將其建模為子流程。

5. 在 Visual Paradigm 中建立模型

Visual Paradigm 提供 BPMN 2.0 建模工具，並支援子流程下鑽，因此高階流程可連結至更詳細的流程圖。其 BPMN 功能還包括記錄工作流程，以及建立現狀與未來狀態的模型。

實用的建立順序：

  1. 建立一個BPMN 業務流程圖於 Visual Paradigm 中。

  2. 新增一個客戶池以及一個公司池；若客戶服務、倉儲與運送等職責重要，則將公司池劃分為對應的泳道。

  3. 放置起始事件與活動，接著加入庫存與付款閘門。

  4. 在公司池內繪製序列流程；與客戶的交換則使用訊息流程。

  5. 以通俗語言標註任務與條件路徑。僅在有助於讀者理解流程之處，才加入資料物件（例如訂單或付款結果）。

  6. 配置圖表使主流程閱讀方向一致（通常為由左至右），並盡量減少連接線交叉。

  7. 與利害關係人檢視圖表。若某步驟的細節遮蔽了主流程，可考慮將該細節置於子流程圖中。

  8. 以適合團隊的格式與工作區儲存並分享模型。

Visual Paradigm 宣稱提供 BPMN 圖表建模、流程下鑽、工作流程記錄，以及現狀與未來狀態建模。特定功能的可用性可能取決於版本。

6. 常見建模錯誤

  • 使用錯誤的連接器：序列流程用於內部流程順序；訊息流程用於參與者之間的溝通。

  • 使用邏輯不清晰的閘門：標註決策及其所有 outgoing 條件。

  • 將每個動作視為獨立泳道池：在同一參與者內使用泳道來表示職責；為不同參與者使用獨立泳道池。

  • 路徑不清晰：顯示拒絕、超時、資訊缺失及其他相關例外情況的處理方式。

  • 單張圖表過度負載：使用子流程將詳細工作與概覽區分開來。

  • 模擬理想狀態而非現實：在提出改進建議前，先準確記錄當前流程。

  • 無目的地添加細節：當資料、事件和任務標記能回答建模或審查問題時，將其納入。

7. 快速審查清單

  • 圖表是否為每個相關路徑明確標示了起始點和終止點？

  • 讀者能否識別出每個活動的執行者？

  • 決策及其 outgoing 條件是否明確？

  • 序列流和訊息流的使用是否恰當？

  • 是否已表示例外情況和替代結果？

  • 圖表在預定的查看尺寸下是否清晰可讀？

  • 執行該流程的人員是否已確認其準確性？