用於產品生命週期管理的 SOA 方法，第 3 部分: 業務流程管理

本文在虛構的 Trucks Inc.的業務問題上下文中討論業務流程管理（Business Process Management，BPM），並對其做出定位。

BPM 是公司需要處理的一項戰略業務決策。Trucks Inc. 對端到端 BPM 並不熟悉。雖然存在一些針對特定過程的文件，但是這些文件基於紙張，沒有關於流程執行時間或成本的可見性。此外，它們從未進行更新，組織中沒有人正式負責確保流程質量和完整性。

應用程式之間的點對點資料流實際上是沒有受到 IT 元件控制的較大業務流程的孤島。Trucks Inc. 曾接受過有關 BPM 優點的教育，並作為其戰略重組活動的一部分對 BPM 工具和方法進行了投資。

與 Trucks Inc. 展開討論的第一個主題是確保他們擁有清楚的流程定義。流程用於橋接業務交付產品、服務或最終可交付件的需求與用於支援該交付的技術之間的差距。可以將流程描述為一組連結在一起的活動，它們接受一個輸入，並對其進行轉換以建立輸出。在理想的情況下，流程中發生的轉換必須為輸入增添價值，並建立對上游或下游接收者更有意義或有效的輸出。可以將 BPM 模型看作是某個時間點捕獲的事實的多維表示形式。該模型具有目的、遠景、受眾、內容、詳細級別以及階段。它用於總結資訊和傳達資訊。流程模型包括流程中所有活動的詳細規範以及關鍵效能指標。

此定義還強調了活動與流程中發生的轉換之間的聯絡。流程的特徵如下：

• 可定義性

它必須具有清楚定義的輸入和輸出邊界。

• 順序

它必須由按照各自的時間和空間位置排序的活動組成。

• 客戶

流程的結果必須有接收者。

• 增值

流程中發生的轉換必須為上游或下游的接收者增添價值。

• 嵌入性

流程不能獨立存在。必須將其嵌入到某個組織結構中。

• 跨功能

流程通常可以跨越多個功能。但不是必須要如此。

• 流程所有權

流程必須有所有者。必須有某個人員負責流程的效能和持續改進。

此外，可以在多個級別定義流程以區分戰略方向、業務執行和技術管理。BPM 社群中有關應該存在多少個級別的流程（以及每個級別的名稱和意圖）的意見各異，但是下面給出了一個示例：

• 第 1 級：企業檢視

從其主要功能或活動類別方面進行描述的業務。

通常根據人員、資源和責任性的使用來劃定邊界。

• 第 2 級：業務功能檢視

第 1 級檢視的一個元件，從其主要功能或活動類別方面進行描述。

• 第 3 級：流程

主要業務功能或活動類別，是第 2 級檢視的元件。

• 第 4 級：子流程

完成第 3 級流程所需要的操作。第 4 級定義完成子流程的概念性方法，並定義用於完成該子流程的最佳實踐。

• 第 5 級：活動

描述構成子流程中包括的一個或多個操作的活動組、活動或工作步驟。這是最詳細級別的流程模型，幷包括服務和整合的捕獲結果。

• 第 6 級：工作步驟

描述構成每個工作步驟的工作步驟詳細資訊。工作步驟的定義應該足夠詳細，以允許對照系統需求進行驗證。

• 第 7 級：步驟指令碼

與工作步驟相關的詳細決策表、測試指令碼、配置設定以及詳細的工作步驟敘述。終端使用者材料、幫助視窗、幫助臺材料以及其他支援教育和培訓的文件。

業務流程管理

BPM 是將軟體功能和業務專業知識相結合來加速流程改進和促進業務創新的學科。由面向服務的體系架構（service oriented architecture，SOA）支援的 BPM 提供了靈活的體系架構樣式，以支援高效的流程更改和快速的流程部署。要讓 BPM 專案取得成功，使用支援 SOA 的軟體和擁有交付及履行 BPM 承諾的專業知識都是非常關鍵的。BPM 已發展到處理現代業務的挑戰，並認識到需要業務方法、組織效率和軟體來處理當今業務的流程需求。

圖 1 BPM 通過利用世界領先的 BPM 應用程式、方法、標準和高度熟練的專業人員，從而處理與業務流程的捕獲、分析採用和執行相關的挑戰

最終，採用 BPM 對 Trucks Inc. 的好處如下：

• 流程洞察和優化

許多合作專案中的第一步是監視正在發生的情況。

瞭解業務中正在發生的情況可以促進相關能力，以增強組織的最重要和最有影響力的部分。

• 加速流程改進

此步驟不只是涉及到改進和優化。它還涉及到您能多快地確定驅動更改的業務部分，以及能多快地實現和部署那些更改以實施改進。

• 適應將來更改的靈活設計

不僅現在做出更改非常重要，而且為每個組織都必須面對的將來更改做好準備也非常重要。

在討論 Trucks Inc. 的 BPM 採用之前，讓我們首先檢查一下他們的業務基礎結構的條件。第一個觀察結果在於，該基礎結構是異構的，並且非常複雜。由於 Trucks Inc. 是通過公司合併形成的，這種複雜性進一步增加。其特徵表現為一系列針對點問題的業務應用程式、多種技術和保持業務正常執行所需要的專門技能集。另一個觀察結果在於，很難獲得駐留在不同 IT 系統中的上下文相關的業務資訊。給定此業務基礎結構，公司 IT 要跟上不斷變化的業務條件幾乎是不可能的。

事實上，IT 很難跟上形勢的發展。更糟糕的是，就 IT 在這些條件下建立或更改應用程式的能力而言，業務部門與 IT 之間已經形成了鴻溝。由於 Trucks Inc. 是通過組織建立而成的，此問題進一步複雜化。作為外部經濟因素，客戶轉移能力、法律法規壓力以及產品和服務開發混雜在一起，推動了對更強的流程靈活性的需要。IT 經常陷入操作和現有應用程式維護之中，而無法及時做出響應。組織推遲進度以等待開發人員更改核心應用程式中嵌入的業務流程是不合理的。話雖如此，對於核心應用程式和基礎結構元素的可用性和可稽核性，IT 必須維持可理解程度的所有權。因此，IT 和業務部門必須採用某種手段有效地協作以完成業務目標。每個實體還必須有某種方法在不影響其他實體的情況下管理和更改其環境。這種多作用和多方面的功能集，以及讓業務使用者能夠建立或更改流程並維護流程可見性的能力，在 BPM 中處於核心地位。

採用流程標準

為了幫助 BPM 方法的採用，Trucks Inc. 檢查了行業標準流程的結構和內容。存在許多可能對 Trucks Inc. 有用的標準流程來源。對於技術級別的工程更改流程的執行，他們可以依賴 Verband der Automobilindustrie (VDA) 組織。VDA 為 ECM 流程提供了有關客戶與供應商之間使用標準進行更改資料交流的支援，例如 ISO10303-214 (STEP AP214) 和 OMG 推出的 PLM 服務。從業務流程的角度看，Trucks Inc. 可以考慮價值鏈操作參考（Value Chain Operations Reference，VCOR）、供應鏈操作參考（Supply Chain Operation Reference，SCOR）或設計鏈操作參考（Design Chain Operations Reference，DCOR）模型，儘管這些模型通常以核心產品開發領域為中心。但是為了擴充套件 BPM 採用的範圍，建議 Trucks Inc. 使用某個特定於行業的流程分類框架（process classification framework，PCF）。最初的通用 PCF 由美國生產力與質量委員會（American Productivity and Quality Council，APQC）組織所建立。有關 APQC 的詳細資訊，請參見以下網站：

http://www.APQC.org

此通用 PCF 是 APQC 在包括 IBM 在內的合作伙伴的支援下建立的。APQC 合作伙伴隨後建立了特定於行業的模型（包括汽車業），並作為開放原始碼標準可用。

這些 PCF 提供了流程的層次結構，任務、決策和角色的術語共性，以及等效於本文前面提到的第 5 級定義的詳細流程模型。

在許多情況下，流程的定義中使用了模式。這些模式是可重複的流程任務或決策分組，在整個端到端流程框架中重用了許多次。流程模式的示例是審查週期。審查在整個產品開發週期中進行，從某人確定新卡車的市場機會開始，到回收有害材料時結束。審查的參與者、資料和位置可能各不相同，但核心步驟是相同的。

1. 確定對審查的需要
2. 收集將要審查的資料並將其分發給審查團隊
3. 審查團隊對後續步驟做出評估（包括他們是能夠自己定義後續步驟還是需要外部勢力）
4. 實施後續步驟。

圖 2 顯示了此審查模式的示例。

圖 2 審查模式示例

除了流程本身以外，PCF 還包括全套關鍵效能指標（key performance indicator，KPI）。通過採用這些 KPI，如果 Trucks Inc. 利用 PCF 並向 APQC 訂閱，則與該標準組織的其他成員相比，他們將能高效地對其業務有效性進行基準測試。作為 BPM 採用的一部分，Trucks Inc. 在法律上必須證明某些流程中的功能，以實現認證和規章遵從性。通過使用為適應 Trucks Inc. 的特定流程需要而定製的行業 PCF，闡明遵從性的挑戰得到了極大的簡化。

有控制的流程靈活性和創新需求

值得注意的是，即使同屬相同垂直市場，也沒有任何兩個組織是完全相同的。雖然他們可能擁有在某些市場的巨集觀級別相當一致的業務流程（例如管理客戶帳單），但是每個公司或組織都會增添自己的細微差別，並定製那些流程版本以反映各自的業務需求。對於受管制的市場，業務流程還必須是可稽核的，並且同樣有不同程度的管制在影響著整個市場的各個組織。

但與此同時，組織還必須在各自的業務實踐中實現創新，無論這意味著尋找改進服務的方法還是縮短產品開發週期以使用高質量的產品和服務更快速地響應市場來實現流程中的這種靈活性。

要處理的廣泛需求

來自合併前的兩家公司的單獨業務最佳實踐、行業標準流程（例如源自 APQC 的標準流程）、針對安全和環境注意事項的法律法規需求以及創新的動力混合在一起，因此 BPM 解決方案必須處理廣泛的流程型別、構成、參與者和效能需求。需求涵蓋以下情況：

• 需要將多個應用程式繫結在一起的流程，以便能夠在應用程式間具有適當控制的情況下對資料進行處理。
• 需要與業務操作（或作為其結果）緊密一致地保留文件並將其宣告為記錄的應用程式。
• 處理異常以及從結構化的流程中解決異常的能力
• 整合共享領域的能力，團隊成員可以在這些領域就專案和相關材料進行合作

處理複雜性：流程和參與者

Trucks Inc. 中存在所有這些需求，必須將它們聯絡起來以處理更加複雜的操作。還必須基於行業和業務法律法規對它們進行監視和稽核。BPM 解決方案必須使組織能夠捕獲和輕鬆更改關鍵流程元素：

• 資訊在人員和系統之間必須經歷的路線
• 參與流程的角色
• 控制這些相互關係的規則和策略

還必須處理參與這些流程的各種各樣的角色。

這包括業務部門流程所有者、提供整合和定製功能的 IT 專業人員、僅檢視跨流程的效能儀表板表示形式的經理和主管，以及可能對流程進行建模和模擬的業務分析人員。BPM 必須提供支援所有上述情況和參與者的定製體驗。

保持以業務使用者為中心

儘管具有可能的複雜性，BPM 必須交付適當的資訊，據以通過直接了當的方式作出決策。

這從對流程進行建模、模擬和修改的能力開始。對於需要人員做出決策的流程，或者對於可能需要人員參與自動化流程的情況，在業務用途的上下文中交付資訊是極為重要的。對於 BPM 解決方案，這意味著處理適當的業務角色、獲得驅動決策所需的有效資訊，以及使使用者能夠在繼續之前與資訊互動。在某些情況下，動態地（例如，在流程預先不知道要呼叫哪一個特定應用程式或服務的情況下）向業務使用者提供正確的應用程式或資訊的能力是一項需求。此外，當需要流程內部或外部的各種資訊來做出決策時，將採用門戶（並最終採用 Web 2.0 技術）向業務使用者交付統一和上下文相關的檢視。

BPM：戰術與戰略方法

在 Trucks Inc. 中開始 BPM 活動時，董事會已決定他們將實現 BPM 以處理新合併的公司中單個業務領域中的特定難點。但是，即使在那些情況下，BPM 解決方案也不會是獨立的孤島。它必須與其他應用程式整合，它必須足夠靈活以允許頻繁地更改流程，它還必須為使用它的人員提供正確的上下文。但與此同時，BPM 也不能犧牲流程靈活性，並且它必須容易與資訊管理工具整合，無論那些工具是用於分析還是與內容相關，以確保為使用者提供他們在適當的上下文中做出決策所需要的內容。

在 Trucks Inc. 處理完整 BPM 實現這個更大戰略目標的時候，上述所有需求都適用，但是所選的 BPM 解決方案集合或組合還必須提供其組成部分之間的互操作性，從而為使用者、經理、開發人員和其他參與者提供有效支援。

供應商還必須提供廣泛的功能以處理組織中的廣泛流程，無論那些流程是協作的還是事務性的，是結構化的還是動態的。同時從流程的範圍內（通過業務活動監視或有關流程效能及基礎結構效能的分析）和流程外的相關應用程式或事件方面優化流程的能力正日益成為一項需求。

動態流程、BPM 和 SOA

必須利用 BPM 與 SOA 的關係，以增強流程中的動態需求，以及反映通過更改組織、市場和業務需求來輕鬆修改基礎結構和整合應用程式的能力。設想建立一個金融帳戶開立流程，該流程足夠靈活，在新客戶提供有關其狀態的資訊和外部系統幫助確定他的信貸價值時，能夠實時確定若干帳戶選項中哪一個選項是適當的；其中只需對流程重新建模以利用新的服務和遵循更改後的業務規則，即可對客戶的信貸價值做出更改。而且隨著流程變得更加複雜以及整合的動態性，那些流程對資訊和內容更改做出反應或輕鬆獲得資訊以實現自動化或人工決策的能力變得前所未有的重要。

BPM 與企業體系架構（Enterprise Architecture，EA）

在 Trucks Inc. 的 BPM 採用過程中，必須從體系架構的角度考慮 BPM，給定該組織對轉向 SOA 的日益增加的需要以及支援資訊基礎結構的相關需求，情況尤其是如此。EA 規程認為存在單獨但相關的業務、資訊和技術體系架構元件。因此，BPM 解決方案必須遵守技術基礎結構和平臺需求，同時還要提供業務靈活性和與資訊管理標準的聯絡。

因此，組織必須考慮提供以下特性的功能和供應商：

• 多個 BPM 入口點

具備如下特徵的一組廣泛的 BPM 功能是至關重要的：它們可互操作但是可分離，並且足夠開放以適應當前和將來的體系架構平臺、應用程式、流程和資訊需求。可分離性非常關鍵，因為並非每種情況都需要 BPM 技術的每個方面。例如，有些組織在對流程監視一段時間之後確定了哪些流程需要優化（以及如何優化）。其他組織面對不斷變化的業務需求，確定了要需要創新的流程。

• 處理多個業務場景的能力

能夠處理從協作到事務的廣泛流程，同時向流程的任何階段中涉及的每類使用者（業務、IT、管理等等）交付適當的上下文重點，這樣的 BPM 技術非常重要。流程起初可以按照主要特徵（例如，線上帳戶開立）進行指定，但是可能需要不同的 BPM 功能以滿足次要需求（例如，需要捕獲文件以滿足規章遵從性的客戶例外情況）。供應商必須提供此係列功能，並在其中提供適當的可互操作性。

• 靈活性和更改流程策略及規則的能力

靈活性是 BPM 技術的一個主要優點，解決方案必須在所有平臺中反映此優點。這意味著流程建模與開發工具和標準整合，同時提供用於流程模擬和優化的資訊並對資訊做出反應。它還需要動態連結和編排外部服務及其他流程以處理更復雜業務情況的能力。必須解決包括及規定協作和麵向團隊的功能以解決例外情況或處理較偶然流程問題的能力。

使用 BPM 處理特定業務需求

為了將採用 BPM 的戰術優點作為某些關鍵業務挑戰的實用解決方案來加以推動，Trucks Inc. 必須確保他們的 BPM 解決方案提供從建模直至監視的全套整合功能，同時確保處理組織確定要實現優化（或者甚至是要實現簡單自動化）的關鍵流程。在優化時，利用直接從流程中得出的分析結果以及與流程相關的外部分析結果（例如，可能影響供應鏈流程的區域銷售資料）的能力正在變得更加關鍵，持續地建立和測量流程 KPI 的能力也是如此。能夠糾正流程，或者推動可以處理通過分析指定的動態業務需求的策略，這將成為下一代 BPM 的標誌。戰術 BPM 方法還必須取得微妙的平衡，既要處理為之做出優化的流程，同時又要提供足夠的迴旋餘地和互操作性以拓寬流程範圍或處理例外。

專業知識

通過行業專業知識快速著手進行流程優化是非常關鍵的，無論那些專業知識是預先建立的基於標準的角色和 KPI、行業基準，還是面向垂直行業的服務。能夠利用反映適當角色、安全性和功能的預定義資料模型或模板，這不僅可以提高實現速度，而且還可以提高可用性並確保普遍性和輕鬆地順應行業預期。

給定通過 BPM 加強組織中業務使用者能力的要求，通過交付熟悉和可接受的使用者環境來方便快捷地處理業務需求的能力極為重要。

使用 SOA 支援的 BPM 加強 LOB 和 IT 的協作能力

雖然配備 IT 的目的是解決複雜技術問題，但是 IT 並不知道如何最佳地優化某個流程，或者必須跟蹤哪些關鍵效能指標才能跟蹤和優化業務效能。直到最近為止，業務部門雖然清楚關鍵業務流程，但是還不具備在條件更改或預期要更改時更改業務流程的能力。

但是，除非 Trucks Inc. 採用某種經過證明的方法，通過該方法建立和部署其 BPM 內容以推動業務導向的更改，否則他們對創新 BPM 軟體的使用將毫無意義。

實現業務流程管理

實現 BPM 的挑戰之一是需要在處理業務級挑戰的自頂向下方法與開發服務的自底向上方法之間取得平衡。為了解決此挑戰，需要在 PLM 領域中的技術和業務架構師達成一致意見的情況下將 Trucks Inc. 流程分離為各個構成元件，應用程式也需要類似的分離。

元件業務建模（Component Business Modelling，CBM）是一種經過證明的方法，可以讓組織通過將活動重新分組到數量可管理的離散、模組化和可重用的元件中，從而確定改進和創新機會。可以使用 CBM 推動自頂向下的開發活動。這可以實現靈活性，並清楚地將重點放在執行業務和推動戰略所需要的核心功能上。

CBM 的主要方面如下：

• 業務元件是企業中具備獨立操作潛力的部分（例如，它具備已定義和已宣告輸入和輸出集，並且可以在有限附加外部影響的情況下執行）。業務元件是企業一部分的邏輯檢視，該部分包括交付價值所必需的資源、人員、技術和專門技能。它具有高度的自主性，單獨進行管理，並通過業務服務和整合資訊系統與組織的其他部分聯絡在一起。
• 業務元件對映是業務元件的表格式檢視。該對映提供有關業務的自頂向下檢視。
• 業務元件模型是用於描述某個企業或行業的業務競爭力、業務元件、業務服務及其關係的術語。

用於重型卡車行業的標準元件業務模型模板已經建立，並形成了 Trucks Inc. 的 CBM 評估的基礎。使用這些模板作為與客戶討論的起點，然後可以根據客戶的工作方式對模板進行專門定製。由於該 CBM 進一步劃分為一套行業流程和子流程（請參見圖 3）以及一套 KPI，因此可以使用此模型來確定業務流程中有待改進的部分。

圖 3 行業流程和子流程的元件業務模型套件

實現 BPM 遠不只是確定流程改進機會那麼簡單。與任何新的戰略方向的實現一樣，不僅必須考慮流程或新技術，而且還必須考慮將執行流程的人員。在採用 BPM 時，Trucks Inc. 必須考慮他們打算做的工作的組織更改管理影響，這其中包括以下影響：

• 組織構造

新流程或技術的採用可能影響當前組織的構造方式。作為 BPM 的一部分，將對組織當前狀態下的效率和所需條件下的預測效率進行評估，並提出有關重大組織重組的建議。

• 教育和培訓

BPM 採用給組織帶來了對附加培訓和教育的需要：教育是關於為什麼給定的角色正在執行某個任務的說明，培訓是確切地說明如何執行某個任務。

在從原有 BPM 狀態轉向將來狀態時，大多數公司都要經歷包括四個階段的實現方法：

• 概念驗證

捕獲新流程的意圖，並短期測試新流程和新技術以捕獲有關新流程有多好、有多廉價或有多快速的指示。此 PoC 階段通常採用測試資料在獨立環境中實施。

• 試驗

進一步測試新工具和流程，通過大量資料和更頻繁的執行為工具和流程施加顯著的負載。通常使用實時資料庫的副本在預生產 IT 環境中執行。

• 實現

將新工具和流程全規模地部署到實時資料之上的使用者社群。

• 支援

提供使用者支援以確保新工具和流程的無縫採用，以及從更廣泛的使用者社群收集反饋。

為了採用 SOA 術語來表達這四個步驟，我們將 BPM 的實現考慮為以下階段

• 建模階段

捕獲當前狀態的靜態流程模型。此原有模型提供了有關當前流程成本和執行時間長度的檢視。

基於 APQC 流程分類框架行業流程建立特定於客戶的動態將來流程，並同樣應用代表性時間和成本資料。原有與將來模擬結果的比較提供了投資回報和業務案例以論證客戶的 BPM 開支的合理性。

除了簡化和有效的業務流程以外，在將來模型中還將捕獲 KPI，用來在該週期中的以後監視流程的執行狀況。在建模階段結束時移交給 IT 架構師的業務成果是業務流程執行語言（Business Process Execution Language，BPEL）模型。

• 組裝階段

IT 架構師實現建模階段中的 BPEL 輸出。

然後開發人員能夠優化流程的執行，基於整合平臺實現策略和規則，並在部署到生產環境之前徹底測試該實現。

• 部署階段

包括人工任務管理在內的流程執行和自動化（工作流和編排）是業務流程的重要元素。

執行是通過流程引擎（最好執行在 ESB 和安全應用程式伺服器上）上部署的組裝活動結果來進行的，並且可以包括與內容管理的整合。在所有業務流程中，隨著工作的推進，都會建立或使用資訊。

內容是要在業務流程中操作的主要物件。

因此，流程參與者需要能夠建立新內容，同時還需要能夠訪問和利用現有內容。正確的時間手邊有正確的資訊可用，對於流程成功至關重要。

• 監視階段

業務活動監視是監視流程效能和檢測可能影響效能的事件的能力。要分析流程效率和有效性並讓流程改進與企業目的和目標保持一致，這涉及到使用諸如 WebSphere Business Monitor 等軟體來偵聽關鍵業務事件、關聯事件資料，以及更新建模階段中捕獲的 KPI。

BPM 工具

在 BPM 內容的建立和部署中，我們向 Trucks Inc. 推薦了以下 WebSphere 產品套件：

• IBM WebSphere Business Modeler

此產品提供流程建模、模擬和分析功能，以幫助業務使用者視覺化、瞭解和記錄業務流程以實現持續改進。除了對資源、角色、組織、資訊和業務度量建模以外，它還使業務使用者能夠對至關重要的業務流程進行設計、建模並做文件記錄。

• IBM WebSphere Integration Developer

在生產環境中進行部署之前，業務流程優化所產生的應用程式和整合的開發、組裝和測試中將使用本產品。它是用於構建跨 WebSphere Process Server、WebSphere ESB 和 WebSphere Adapters 的基於 SOA 的解決方案的公共工具。

• IBM WebSphere Process Server

此產品通過自動化任務和人工任務來管理 WID 中定義的流程、整合和應用程式的執行。

• IBM WebSphere Business Monitor

此產品通過以下功能提供業務效能的端到端可見性：

• 可自定義的儀表板
• 針對新出現的業務情況的早期檢測和警報
• 用於實現流程改進的完整 WebSphere Business Modeler 反饋機制
• 顯示在儀表板上的近實時資訊

這些功能提供了做出及時更改和執行高階分析以基於歷史記錄和趨勢資料制定決策的能力。除了處理從事件源接收的事件以外，WebSphere Business Monitor 還可以將其他業務參考資訊引入 Business Monitor Server。與 WebSphere Integration Developer 和 WebSphere Process Server 整合以後，WebSphere Business Monitor 可以全程跟蹤 WebSphere Enterprise Service Bus 和 WebSphere Process Server 中執行的所有元件的活動。

• IBM WebSphere Business Services Fabric

此產品使業務使用者能夠根據不斷變化的環境動態地更改和適應（例如，在開發週期中的不同部分使用替代供應商，或者能夠根據一組業務規則做出更改）。請參見圖 4。

圖4 用於 SOA 實現的 BPM 的四個主要階段之間的聯絡的圖形表示形式以及關聯工具

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-584504/，如需轉載，請註明出處，否則將追究法律責任。