引言
在業務流程管理的世界中，清晰度與細節之間始終存在著矛盾。利益相關者希望看到能放在單一簡報頁上的高階概覽，而運營團隊則需要細緻的指示，以無歧義地執行任務。多年來，我目睹許多組織在這兩者之間難以取得平衡，往往導致圖表過於龐大且難以閱讀，對兩方都無法提供有效幫助。
最近，我有機會深入研究一項案例，涉及一家中大型組織的人力資源部門。他們面臨一個典型的擴展性問題：如何在不造成混亂的情況下，管理大量職位申請，並應用多層級評估標準。他們所採用的解決方案，充分利用了BPMN 2.0中最強大卻鮮少被使用的功能之一：嵌入式子流程.
本指南分享了我評估他們方法的經驗，剖析了為何將「任務」與「子流程」分離，不僅是視覺上的選擇，更是可擴展工作流程的架構必要。無論你是業務分析師、人力資源運營經理，還是流程架構師，本評估都能提供實用的洞見，幫助你在保持高階可讀性的同時，建模複雜的決策邏輯。
1. 問題所在：招聘流程變得複雜時
該人力資源部門面臨幾個關鍵挑戰：
- 高數量：數百份申請需要系統性篩選。
- 多層級標準：候選人需要同時通過正式資格審查（學位、證照）與職位匹配度評估。
- 決策複雜性：候選人可能不適合所申請的職位，卻可能非常適合另一個開放職位。
- 可審計性：管理者需要清楚地掌握原因申請被接受或拒絕的原因。
- 可擴展性：隨著公司成長，平面圖表變得過於複雜，難以維護。
核心業務問題是：「我們該如何建模招聘流程，使其既足以讓高階主管一目了然地理解，又細節充足，讓人力資源分析師能一致地執行？」
答案在於層級化建模。
2. 概念基礎：任務與子流程
在查看圖表之前，理解「任務」與「子流程」之間的差異至關重要。這正是清晰BPMN建模的基礎。
| 功能 | 任務 | 子流程 |
|---|---|---|
| 定義 | 一個不可再分的工作原子單位；在目前的模型中不再進一步細分。 | 一個包含自身內部任務、閘道與事件流程的複合活動。 |
| 符號表示法 | 圓角矩形。 | 圓角矩形，底部中央帶有+符號。 |
| 可擴展性 | 稍後可進一步細分，但在此處視為原子單位。 | 已包含詳細的子流程。 |
| 令牌行為 | 令牌進入 → 工作完成 → 令牌退出。 | 令牌觸發子流程開始 → 流經子流程 → 到達結束事件 → 令牌傳遞至父流程。 |
| 目的 | 簡潔性、抽象化。 | 複雜邏輯的封裝。 |
重要注意事項：將「提交申請」建模為一項任務，並不代表無法進一步細分。這僅表示在此特定模型中尚未進行細分這僅表示在此特定模型中尚未進行細分在這個特定模型中。這是一種建模選擇，而非永久性限制。
BPMN 中的閘道根據條件控制序列流的分支或匯合，作為父流程與子流程內的決策點。
3. 圖示說明：父流程
模型的第一層是為高階決策者設計的。它提供招聘流程的高階視圖，而不會陷入審核具體標準的細節中。
圖示：父流程 — 包含子流程「審核申請」的流程
（註：在原始上下文中，此圖示顯示高階流程。想像一個開始事件引導至「填寫申請」，接著到「審核申請 ⊕」，然後透過閘道分為「邀請面試」或「拒絕申請」。）
逐元素解析
| 元素 | 類型 | 角色 |
|---|---|---|
| ○（細圓圈） | 開始事件 | 當提交申請時，觸發整個流程。 |
| [填寫申請] | 任務 | 捕捉/記錄候選人的申請資料；在此層級為原子性。 |
| [審核申請 ⊕] | 嵌入式子流程 | 包含完整的多步驟評估邏輯；以「+」標示。 |
| ◇（菱形） | 排他閘道（XOR） | 根據子流程的結果（「正面」或「負面」）來導向流程。 |
| [邀請面試] | 任務 | 僅在審核結果為正面時執行。 |
| [拒絕申請] | 任務 | 僅在審核結果為負面時執行。 |
| ◎（粗圓圈） | 結束事件 | 終止流程的相應分支。 |
關鍵行為規則：
在父流程中，無論子流程內達到哪個結束事件都無關緊要。哪一個結束事件被觸發。重要的是子流程已經完成。完全完成在代幣傳遞到出站序列流之前。網關隨後評估資料由子流程產生的（例如，一個稱為"結果"具有值"正面"或"負面") 以決定路由路徑。
4. 圖表說明：子流程
對於需要一致執行審查的HR分析師而言，子流程會被展開。這揭示了「+」符號背後隱藏的詳細邏輯。
圖：子流程 — 子流程「審查申請」（展開視圖）
（註：在原始情境中，此圖表顯示內部邏輯。想像一個開始事件引導至「審查正式資格」，接著是一個網關。如果符合，則進入「檢查申請人是否適合該職位」。如果不符，可能會進入「檢查申請人是否適合另一個開放職位」。所有路徑最終都會導向「正面結果」或「負面結果」結束事件。）
逐元素解析
| 元素 | 類型 | 角色 |
|---|---|---|
| ○（細圓圈） | 開始事件 | 當父流程代幣到達時自動觸發。 |
| [審查正式資格] | 任務 | 第一個評估步驟：驗證學位、證書、經驗門檻。 |
| ◇ 網關 #1 | 獨佔網關 | 決策：正式資格是否符合或不符合？ |
| [檢查申請人是否適合該職位] | 任務 | 第二個評估：根據特定職位評估技能/經驗的匹配程度。 |
| ◇ 網關 #2 | 獨佔網關 | 決策：申請人是否符合申請的職位？ |
| [檢查申請人是否符合其他開放職位] | 任務 | 第三次評估（備用）：搜尋其他開放職位，尋找可能的匹配。 |
| ◇ 網關 #3 | 獨佔網關 | 決策：申請人是否符合任何其他開放職位？ |
| ◎ 正面結果 | 結束事件 | 信號成功審核；設定 result = "正面". |
| ◎ 負面結果 | 結束事件 | 信號審核失敗；設定 result = "負面". |
令牌流邏輯
- 一個令牌從父流程到達 → 觸發子流程的開始事件。
- 令牌流經 審查正式資格.
- 如果資格審查失敗 → 直接跳轉至 負面結果 結束事件。
- 如果資格審查通過 → 繼續至 檢查申請人是否符合職位.
- 如果符合 → 則轉至正面結果結束事件。
- 如果不符合 → 嘗試檢查申請人是否符合其他開放職位.
- 如果符合其他職位 →正面結果；否則 →負面結果.
- 當達到任何結束事件時，子流程即完成，並發出一個訊號回父流程的輸出流程。
5. 解釋與資料流語義
這是個案研究中最細膩的部分。BPMN語法中存在明顯的矛盾：
「根據BPMN語法，子流程內的不同結束事件與上層流程中決策網關的條件之間並無直接關聯。」
在嚴格的BPMN術語中，父流程的網關無法「看見」哪個子流程中達到了哪個結束事件。那麼父流程如何知道應該轉至「邀請面試」還是「拒絕申請」？
解決方案：資料屬性
正確的解釋是，子流程會產生資料。具體而言，一個稱為「result」的流程屬性會接收值「positive」或「negative」，取決於所採取的內部路徑。由於流程中的所有資料在任何地方都可取得，包括嵌入的子流程以及回到父流程，因此父流程中的網關條件只需評估此屬性：
- 條件：
result == "positive"→ 轉向「邀請面試」 - 條件：
result == "否定"→ 轉向「拒絕申請」
同樣地，子流程內部的閘道也可以讀取和寫入 "result" 屬性。
這在實際上為何重要
此模式可確保：
- ✅ 鬆散耦合 父流程與子流程邏輯之間的鬆散耦合。
- ✅ 可重用性： 「審核申請」子流程可從多個父流程中被調用。
- ✅ 可維護性： 審核標準的變更僅需修改子流程，無需修改父流程。
- ✅ 合規性： 每個決策點均可審計，並具有明確的資料追蹤。
6. 何時使用子流程與任務
根據此案例研究與BPMN最佳實務，以下是您自身建模工作所用的決策框架。
✅ 當以下情況時使用子流程：
| 情境 | 案例研究中的範例 |
|---|---|
| 複雜的內部邏輯 包含多個決策點 | 「審核申請」內部有3個閘道與4個任務。 |
| 可重用的流程片段在多個父流程中使用 | 相同的審核邏輯也適用於內部調動、晉升等情況。 |
| 團隊所有權邊界 | 人力資源運營負責「審核申請」；招聘部門負責「邀請面試」。 |
| 圖表可讀性 | 將兩個圖形合併為一個將產生8個以上的節點，難以閱讀。 |
| 層級化報告需求 | 高階主管查看父節點；人力資源分析師則處理子節點。 |
| 獨立的生命周期管理 | 審核標準每季變更；面試排程邏輯每年變更。 |
最佳實務建議建立層次化的多層流程模型，並使用子流程將流程拆分為邏輯階段。
✅ 當以下情況時使用任務：
| 情境 | 案例研究中的範例 |
|---|---|
| 原子性、不可分割的工作在目前的建模範圍內 | 「填寫申請」僅為單一表單輸入動作。 |
| 簡單性已足夠—— 無需內部分支 | 「邀請面試」為直接的通知/郵件任務。 |
| 未來可擴展，但目前尚不需要 | 「填寫申請」未來可擴展以包含文件上傳、驗證等。 |
| 外部系統呼叫—— 表示為單一服務任務 | 呼叫外部ATS API以儲存申請資料。 |
💡 建模原則：始終根據您的受眾，以適當的抽象層次進行建模。今日的任務隨著需求演變，明日可能轉為子流程——這是一項功能，而非限制。
7. 展示的BPMN最佳實務
本案例研究突顯了幾項關鍵最佳實務：
- 層次化分層：兩個清晰的層級——戰略概覽與操作細節——遵循建議，建立多層次流程架構。
- 一致的網關使用：在每個分支點，皆正確使用排他性網關來處理互斥的決策路徑。
- 明確標籤：每個從網關流出的序列流皆以條件標示（例如「正面結果」、「正式資格合格」等）——這是一項被廣泛認可的提升可讀性的最佳實務。
- 單一入口，受控出口：子流程具有一個起始事件和恰好兩個結束事件，使其與父流程的合約關係明確。
- 以資料為中心的決策制定：而非依賴隱含的令牌路由，明確的資料屬性（「result」）驅動網關條件——提升可追蹤性與可測試性。
- 標準符號符合性：所有元素均使用正確的BPMN 2.0符號，確保跨建模工具的互操作性。
8. 總結表格
| 面向 | 細節 |
|---|---|
| 領域 | 人力資源／招募 |
| 流程名稱 | 申請審核與面試決策 |
| BPMN模式 | 內嵌子流程搭配資料驅動的網關路由 |
| 父流程節點 | 1 個起始點，2 個任務，1 個子流程，1 個網關，2 個結束事件 |
| 子流程節點 | 1 個起始點，3 個任務，3 個網關，2 個結束事件 |
| 關鍵資料屬性 | result∈ {「positive」, 「negative」} |
| 主要優勢 | 關注點分離；可擴展、可維護、可審計的流程模型 |
| 適用標準 | BPMN 2.0（ISO/IEC 19510） |
9. 擴展與變體
此案例研究可從多個方向進行擴展，以處理更複雜的場景：
- 呼叫活動：如果「審核申請」在多個招聘流程中共享，請以可重用的呼叫活動（全域子流程）取代嵌入的子流程。
- 事件子流程：新增一個中斷型計時器事件子流程，於申請人30天無活動後自動拒絕申請。
- 訊息事件：以訊息啟動事件取代起始事件，透過電子郵件或API觸發流程。
- 多實例子流程：若需多位審核員獨立評估同一申請，應將「審核申請」建模為具有並行執行的多實例子流程。
- 補償：若後續背景調查失敗，新增補償處理器以撤銷「邀請面試」。
結論
此案例研究顯示，BPMN子流程不僅僅是視覺上的便利——它們是基本的架構機制用於管理業務流程模型複雜性的基本架構機制。透過將多步驟的「審核申請」邏輯封裝於子流程中，組織在高階管理層面實現清晰性，同時在運營層面保留分析深度，所有環節均透過明確定義的資料合約連接，而非脆弱的隱式依賴關係。
對於任何希望實現類似工作流程的人，Visual Paradigm等工具提供強大的支援。Visual Paradigm提供對這些模式的強大支援。其具備AI驅動的圖形生成、流程模擬及團隊協作功能，簡化了符合標準的BPMN 2.0模型的建立。無論您是繪製「現狀」流程，還是設計「未來」改進方案，採用層次化建模都能確保您的流程保持可擴展、可維護，並對所有利益相關者清晰明瞭。
參考文獻
- Visual Paradigm 功能：Visual Paradigm 提供一個完整且符合標準的BPMN 2.0建模平台，專為業務分析師與開發人員設計，結合傳統圖示繪製與先進的自動化與模擬功能。
- BP建模解決方案：提供智慧連接規則、靈活的泳道編輯以及以資源為中心的建模，以優化運營工作流程，並防止無效的流程路徑。
- AI BPMN生成器指南：說明如何使用AI BPMN圖形生成器自動將純英文流程敘述轉換為完全互動且符合標準的BPMN 2.0佈局。
- BPMN輕鬆上手: 強調簡化BPMN建模的工具，包括流程動畫和非技術利益相關者的差距分析。
- BPMN 教學 1: 提供BPMN符號的基礎教學，包括事件、特殊任務類型、網關和資料物件。
- BPMN 教學 PDF: 可下載的PDF版本基礎BPMN教學，供離線參考。
- BPMN 活動類型說明: 詳細指南，說明不同的BPMN活動類型，協助使用者在服務、使用者、手動和腳本任務之間做出選擇。
- Visual Paradigm YouTube示範: Visual Paradigm功能的影片示範，包括泳道編輯和流程下探功能。
- SysML 建模指南: 討論以資源為中心的建模，其中元件被建立為可重複使用的模型組件，而非靜態形狀。
- BPMN 泳道教學: 專注於使用互動式水平或垂直池與泳道來分割流程。
- BPMN 圖表工具概覽: 重申BPMN圖表繪製的完整功能集，包括完整的符號支援與人工智慧整合。
- Visual Paradigm部落格: 討論Visual Paradigm作為一體化軟體解決方案，強調其在軟體開發與流程建模中的角色。
- 業務流程建模指南: 涵蓋業務流程建模的最佳實務，包括現狀（As-Is）與目標狀態（To-Be）的差距分析。
- BPMN 功能清單: 列出關鍵功能，例如流程模擬、動畫以及RACI/CRUD輸出的矩陣轉換。
- Visual-Diff功能: 解釋版本比較工具，透過視覺化比較不同工作流程版本，追蹤操作上的變更。
- REST API設計解決方案: 強調敏捷整合功能，將工作流程元件同步至使用者故事和開發待辦事項中。