業務流程模型與符號（BPMN）作為描述工作流程的通用語言。在此框架中，流程的清晰度通常取決於邊界定義得是否明確。開始事件和結束事件是任何流程圖的關鍵。它們標示出業務活動的起點與終點。錯誤使用這些元素，可能導致對流程實際啟動時間以及何時被視為完成產生混淆。
本指南探討如何正確使用開始與結束事件來明確流程觸發。我們將檢視這些事件的語義、其視覺表現形式，以及針對不同情境可用的具體類型。正確的建模可確保利益相關者無歧義地理解流程實例的生命周期。
🌱 開始事件的角色
開始事件代表流程啟動的時刻。它是觸發流程新實例創建的條件。視覺上，它以一個邊框較細的圓圈表示。內部通常為白色，表示在觸發發生前不會有任何動作。與由參與者執行的任務不同，開始事件是一種必須滿足才能開始工作的條件。
定義觸發條件
每個開始事件都需要一個特定的觸發條件。若無觸發條件，流程將無法啟動。觸發條件的類型決定了流程的性質。以下是BPMN中常用的開始事件類型：
-
無： 這是預設類型。表示流程在人工或系統手動啟動時開始，且無特定外部訊號。通常用於內部流程。
-
訊息： 當從外部參與者或系統收到特定訊息時，流程開始。這在B2B互動或客戶服務流程中很常見。
-
計時器： 流程根據時間計畫啟動。例如，每月報告可能在每月第一天自動開始。
-
信號： 流程由廣播給多個監聽者的信號觸發。這允許多個流程同時因單一事件而啟動。
-
條件： 當特定條件成立時，流程開始。這在第一個事件中較不常見，但可在特定建模情境中使用。
選擇正確的開始事件類型對於清晰表達至關重要。若流程依賴於客戶郵件，使用「無」開始事件可能暗示需手動啟動，而使用「訊息」開始事件則能準確反映郵件的自動接收。無開始事件可能暗示需手動啟動，而使用「訊息」開始事件則能準確反映郵件的自動接收。訊息開始事件能準確反映該郵件的自動接收。
🛑 結束事件的角色
相反地，結束事件標示流程的終止。它表示業務活動已成功完成，或因異常而中止。視覺上，這也是一個圓圈，但邊框較粗。內部通常為白色，與開始事件類似。
正如流程需要明確的起點，也需要明確的終點。模糊的結束事件會讓利益相關者困惑於任務是否仍在進行中，或工作流程是否已完成。結束事件同時也作為流程實例的終止者，釋放與該實例相關的資源。
結束事件的類型
不同情境需要不同類型的結束事件。選擇正確的類型可清楚傳達流程的結果：
-
終止： 此事件立即結束流程。通常在滿足關鍵條件時使用，例如取消請求。
-
訊息： 該流程在向外部參與者發送特定訊息後結束。這確認了工作流已完成其通信迴圈。
-
錯誤： 這表示流程因錯誤而結束。追蹤失敗的流程並理解業務活動未能成功的原因至關重要。
-
升級： 當流程因問題被升級至更高管理層而結束時使用。
-
補償： 若活動需要撤銷，則觸發補償流程。此功能用於長時間運行的交易中。
-
信號： 與開始事件類似，此事件在完成時廣播信號，使其他流程能夠對完成狀態作出反應。
-
多種： 根據所採取的路徑，允許流程以多種方式結束。
使用終止事件與訊息事件不同。終止 會立即停止所有內容。訊息 會在停止前發送通知。理解此區別可避免對系統是否仍處於活躍狀態產生混淆。
📊 開始與結束事件類型比較
為幫助直觀理解差異，請考慮以下比較常見開始與結束事件類型的表格。此結構有助於為您的特定業務情境選擇合適的元件。
|
事件類型 |
視覺指示 |
主要用途 |
方向 |
|---|---|---|---|
|
訊息 |
信封圖示 |
外部通訊 |
開始與結束 |
|
計時器 |
時鐘圖示 |
預定執行 |
開始與結束 |
|
錯誤 |
驚嘆號圖示 |
例外處理 |
僅結束 |
|
終止 |
紅色 X 圖示 |
立即停止 |
僅結束 |
|
信號 |
閃電圖示 |
全域廣播 |
開始與結束 |
|
無 |
空白圓圈 |
手動啟動 |
僅開始 |
請注意，某些事件（如錯誤和終止）通常是結束事件，而其他事件（如無）通常是開始事件。將這些混合使用可能會導致建模錯誤。
🔍 明確流程觸發條件
「觸發」一詞指的是促使流程前進的事件。在BPMN中，開始事件是主要的觸發條件。然而，觸發條件也可能出現在流程內部，通常作為中間事件。本指南的重點在於邊界。
正確識別觸發條件，可確保流程能回應業務需求。若流程設計為僅在收到付款時啟動，則開始事件必須是代表該付款的訊息事件。若將其建模為計時器事件，系統可能會等待特定日期，完全忽略付款狀態。
常見的觸發情境
-
客戶詢問： 處理客戶投訴的流程應以代表收到郵件或工單的訊息事件開始。
-
每月結算： 財務流程應以設定於每月最後一天的計時器事件開始。
-
系統關機： 維護流程可能由基礎設施團隊廣播的訊號事件開始。
-
手動入職： 招聘流程可能以一個無事件開始，等待招聘人員手動點擊按鈕以啟動。
每個情境都需要採用不同的建模方法。開始事件是業務與系統之間的契約，它定義了工作開始的承諾。
⚠️ 常見的建模錯誤
即使經驗豐富的建模者在定義開始與結束事件時也可能出錯。這些錯誤可能導致難以執行或監控的流程。以下是需要避免的一些常見陷阱。
1. 無閘門的多個開始事件
單一流程定義通常應僅有一個開始事件。如果你發現需要多個開始事件，應考慮使用流程子流程或閘門。擁有兩個開始事件可能會讓執行引擎混淆應創建哪個實例。
2. 缺少結束事件
流程中的每條路徑都必須導向一個結束事件。如果某條路徑在沒有終止點的任務或閘門處結束，流程實例將掛起。它會消耗資源卻無法完成。務必確保每個分支都連接到一個結束事件。
3. 使用任務代替事件
不要使用任務來表示流程的開始。任務暗示著立即開始工作。開始事件則暗示著某個條件正在等待被滿足。使用任務作為觸發條件，可能會導致對工作是否為可選或必選產生混淆。
4. 結束狀態不明確
不要對所有結果都使用通用的結束事件。如果流程因付款失敗而結束，請使用錯誤結束事件。如果因成功完成而結束，請使用訊息事件或無事件結束。區分成功與失敗對於報告至關重要。
🛠 清晰度的最佳實務
為確保您的流程圖清晰且有效，使用開始與結束事件時請遵循以下最佳實務。
-
命名一致性：明確標示您的事件。不要僅使用「開始」，而應使用「開始：訂單已收到」。不要僅使用「結束」，而應使用「結束：訂單已出貨」。這樣可以在不需額外文字的情況下提供上下文。
-
視覺層級： 確保開始事件位於左上角，結束事件位於右下角。這符合自然的閱讀方向，並降低認知負荷。
-
邊界檢查： 定期審查您的圖表，確保沒有路徑成為孤兒。每條序列流最終都必須到達一個結束事件。
-
範圍定義： 明確定義流程實例涵蓋的範圍。如果流程涉及多個部門，請確保開始事件反映的是整個組織的入口點，而非僅僅是某個部門。
-
文件記錄： 為複雜的開始與結束事件添加文件註解。如果僅靠圖示無法充分說明，請在註解欄位中解釋具體的觸發條件。
🔗 子流程與事件處理
在建模複雜系統時，您經常會遇到子流程。這些是包含在另一個流程中的流程。子流程的開始與結束事件對於定義父流程與子流程之間的互動至關重要。
嵌入式子流程
在嵌入式子流程中，開始事件隱藏在邊界內部。父流程無法看到內部的開始事件，僅看到進入子流程的動作。這對於隱藏複雜性非常有用。
事件子流程
事件子流程允許流程在主流程執行時對事件做出回應。它們在邊界內擁有自己的開始事件，並獨立於主流程觸發。這是一項強大的功能，可在不中斷主工作流的情況下處理中斷。
使用事件子流程時，請確保開始事件標示清楚，應明確指出觸發子流程的事件。例如：「錯誤處理器：超時時啟動」。
⚙️ 錯誤處理與結束事件
錯誤處理是流程建模中至關重要的環節。當流程遇到錯誤時，必須知道如何回應。結束事件在此扮演角色，但通常會使用中間事件來捕獲錯誤。
然而，最終的結束事件必須反映實際結果。如果流程失敗且無法恢復，應以錯誤結束事件結束。這會向監控系統發出訊號，表示該流程實例處於失敗狀態。
補償流程
在長時間執行的流程中，您可能需要撤銷已完成的工作。如果流程提前終止，可能需要觸發補償流程。這通常與補償結束事件相關聯，以確保即使流程提前停止，財務或資料完整性仍能維持。
🔄 生命週期與狀態管理
理解流程實例的生命週期是管理開始與結束事件的關鍵。生命週期從開始事件觸發的瞬間開始，到達結束事件時結束。
-
建立： 開始事件建立實例。
-
執行： 任務與網關被執行。
-
終止： 結束事件關閉實例。
如果流程未達到結束事件，它將保持在執行狀態。這會消耗系統記憶體與資料庫空間。定期審核流程有助於識別卡住的實例，並需要手動干預。
📝 最後的考量
建模開始與結束事件不僅僅是畫圓圈。這是在定義您業務的邏輯。這些事件作為人類世界與數位工作流程之間的介面。正確使用時，能清楚說明工作何時開始、何時結束。
透過避免常見錯誤並遵循最佳實務，您可以建立易於理解與執行的圖表。請記得為您的特定觸發條件選擇正確的事件類型。使用粗邊框表示終止，細邊框表示啟動。確保每條路徑都導向明確的結論。
BPMN 的目標是溝通。明確的開始與結束事件能促進利益相關者、開發人員與業務使用者之間的更好溝通。它們能減少歧義，確保所有人對流程邊界有相同的理解。
花時間審查您的圖表。問問自己，開始事件是否真正反映業務觸發條件？結束事件是否準確反映業務結果？對這些元素進行微小調整，可顯著提升流程模型的品質。
