BPM≠Workflow+EAI (下)

在這篇文章中我會繼續將最後兩個階段介紹完，並把BPMS的系統架構與各功能模組作個整理，讓讀者有全盤性的瞭解。

第四階段、管理維護(Administration)：

當流程上線後伴隨產生了管理維護的問題，如例外狀況的介入處理、組織人員的變更、流程重新分派、或流程版本升級的影響。在此，有個重要的模組稱作流程活動監控 (BAM, Business Activity Monitoring)，它可以隨時回報流程的執行狀態與過程，而且使用者也可以設定流程要追蹤的關卡並主動回報，具有預警功能並能隨時掌握問題處理的時效。另外伺服器的流量與執行監控及流程倉儲的資料維護的效能也相當重要。

第五階段、流程最佳化(Optimization)：

流程改善(Improvement)是個持續性的活動，不斷反覆朝向最佳化邁進。流程測量 (Measurement)能提供流程的執行績效(Performance)；BPMS的報表工具(Reporting Tools)能讓企業對自己的組織行為充分了解作為持續改善的依據，如此方能策劃出改善與最佳化的策略。流程分析/模擬著重在執行前的分析，例如自動偵測瓶頸(bottleneck)、死結(deadlock)與流程定義的不一致(Consistence)；而流程測量則是執行後實際資料的分析，可以清楚知道流程消耗時間與資源。這個階段跟商業智慧 (BI, Business Intelligence)的技術與主題相似性很高的，差異在BPMS可以自動紀錄與收集流程相關的資料。尤其BPMS所附含的流程績效儀表版(Dashboard)，它提供一個全面式的概觀讓主管簡單掌握且一目了然哪些流程是在標準差內，哪些是在失控狀態。當然這些報表，都是使用者可以自行定義或查詢的，不用IT人員的參與。

BPM ＞ Workflow +EAI

相信從上述的介紹，讀者可以清楚認識到BPM絕對大於Workflow 加EAI。BPM的主要精神在於企業流程的管理，且主要的焦點在於業務性使用者(business users)而非技術性使用者(technical users)；在於流程彈性即時調整而非資料與應用系統的整合。所以僅是工作流程自動化加上EAI企業應用軟體的轉換機制是不足以的涵蓋企業管理流程中所有必要的環節。例如尚有讓管理主管能即時掌握流程成本效率(cost/effective)評量與流程績效(Performance)管理，業務性使用者可以輕易調整組裝流程以提供客戶最佳業務服務，等等。 我將上述中的工具整合起來，架構如圖二所述：

圖二、BPMS 系統架構圖

一個完整的BPMS系統需由流程設計環境(Process Design Environment)、流程倉儲或儲存庫(Process Repository)、流程伺服器(Process Server)、使用者執行環境(User Execution Environment)等主要元素所架構而成。

流程設計環境 (Process Design Environment)

流程設計環境扮演著流程設計階段中最重要的流程建模工作，通常包含了「組織圖」(Organization chart)、「電子化表單」 (e-form)、活動圖(Activity Diagram) 、與商業規則(Business Rule)等相關元素，並可透過直覺圖形化的介面，協助流程設計者進行企業流程的建構。 組織圖部份大多與組織目錄服務系統(Directory system)相結合，以協助企業進行組織的調整與管理，如支援LDAP、AD等相關目錄服務。而電子表單指的是資訊呈現的介面，一般而言可將應用系統的資料與流程相關的資料，透過所謂的電子表單來展現，便於處理與人互動的部分，而呈現的方式可透過特定的工具快速的訂製。在了解流程整體運作與規劃中，透過活動圖可清楚地規劃與了解流程中的各個活動彼此的先後順序與關聯，並訂定流程的運作條件與事件觸發的相關動作，再透過結合商業邏輯（Business Rule）的方式，讓企業更清楚流程的運作方式且易於修改，在採購流程中，若採購金額大於100,000台幣者需簽核至協理，其餘僅需簽至經理，就是個明顯的例子。

流程模擬（Simulator）與流程設計分析（Analyzer），則是透過流程資料的模擬得以事先驗證流程執行時的結果與流程設計關聯的分析（如在複雜的流程中，重要的流程元素或關聯未建立），達到流程執行前事先的預防，並確認設計的流程是否正確合適或最佳化。

流程資料儲存庫 (Process Repository)

流程倉儲包含了流程定義(Process Definition)、流程執行紀錄(Execution Log) 、與應用資料(Application Data)。流程定義包括了流程運作所有相關的資料，最明顯的就是流程三要素：人、活動與文件，都紀錄在流程定義中，藉由流程的規則引擎(Rule Engine)的參數即資料的變異數或是各個節點所制定的活動時間限制等定出合適的流程定義，最後透過流程伺服器執行定義好的流程；流程執行紀錄指的是流程執行過程中所有的紀錄，有的BPMS將此部份內建於系統中，有的則是需另行將所需紀錄抄寫到資料庫中；應用資料則是指在流程執行的過程中，所使用到其他系統的相關資料並隨著流程紀錄下來或有所關聯，如請採購流程執行中，需依照既有ERP系統的相關資料進行邏輯判斷，甚至需將其抄寫至流程表單中。而在此所指的應用性資料並沒有只侷限在內部資料庫，也包含了根據流程的定義向組織外可能以web service的方式呼叫外部資料來應用。

流程引擎/伺服器 (Process Engine/Server)

流程引擎是整個BPMS中最重要的一環，它負責正確無誤地將流程在正確的時間傳送給正確的人或系統，而由於流程的運作為企業營運的核心，因此能處理複雜且大量的流程工作是流程引擎所必備的條件。分散式交易(Distributed transaction)的管理與負載平衡（Load Balancing）將是考量的重點。

使用者執行環境 (User Execution Environment )

這邊所說的使用者環境指的就是使用者與流程溝通的介面。一般簡易的使用者介面多藉由待辦事項（Work lists ）讓使用者使用流程工作。而由於企業入口網站的風行，一個面面俱到的BPM產品通常透過Web-based介面，並加入口網站（ Portal）的概念，提供所謂的流程入口網站介面（Process Portal）作為使用者使用流程的溝通介面。如此除了可清楚地看到透過流程引擎指派而產生的的各項任務或工作事項(work items)外，並可結合其他入口網站與應用系統整合的機制，如使用協同工作功能促進員工彼此溝通與交流，像是公佈欄、行事曆或討論區等。另外也可透過待辦事項的啟動(trigger)能夠呼叫(invoke)與之相關的應用程式(applications)甚至根據各清楚定義的個別關卡(activity)自動以web service的方式來跨組織地呼叫(invoke)外部資料作交易(transaction)達到名副其實的SOA技術架構概念。

此外藉由流程網站介面使用者(通常指中階以上主管或部門主管)可利用行政管理工具(Administrator Tools)與報表工具(Reporting Tool)。就行政管理工具來說，進入流程資料儲存庫撈取流程定義的資訊所作出的製式化報表可以清楚的知道員工的工作負荷量的輕重程度；而各種的統計量表包含熱門排行、單位時間工作量統計、單位工作量統計、部門工作量統計、流程工作量統計、專案工作量統計提供管理者使用，使管理人員隨時了解企業流程運作的各種情況。使用者也能以web service的方式撈取應用資料作出動態分析。而流程的監控與管理(Activity Monitor)，亦可讓使用者或管理者透過Web的方式，即時地追蹤目前流程的進度或進行例外的處理以能做到修正或變動的因應。也就是說活動的監控對流程範例的執行提供了一個績效量測的準則。最後透過上述工具使流程作到即時的修正達到最佳化讓工作更有效率。