作者:梁賓先
轉載自:http://taiwan.cnet.com
在談完 BPM 相關標準之后，這次我想跟讀者談 BPMS 的架構、組成模塊及其各自功能，讓讀者有全盤性的了解，希望能破除一般人對 BPMS 的迷思。
關于 BPM ，業界有些迷思。例如，常聽到有人說 BPM = EAI + Workflow ； PBMS 只不過 Workflow 廠商的舊瓶新酒，換湯不換藥，只要原來 WfMS 加上系統整合的 Adaptors 就變成 BPMS ；或是 EAI 廠商加上 Activity Modeling 的工具或者是 Routing Engine 重新包裝一下，也可以稱作 BPMS 。
我認為 BPMS 不只是如此，而是一個生命周期。順著 BPM 生命周期了解用戶的操作場景 (Scenario) ，是理解 BPMS 的組成全貌最好且最直覺的方式。在本文中，我首先介紹完整 BPM 生命周期，并從其中的每一步驟接著介紹工作內容、使用到的工具及其功能、與用戶的角色。最后，我會以一張完整的 BPMS 架構圖，詳細介紹其中組成的模塊功能。
BPM ：也要談生命周期 (Life Cycle)
BPMS 強調讓企業可以靈敏反應外部環境的變動并快速變動企業內部的流程作業，所以生命周期所強調的是持續性改善與周而復始的循環。 BPM 生命周期另一個含意就是，它是 BPMS 工具導入的方法論 (Methodology) 。 BPMS 解決方案最重要的核心就是方法論，它至少要包含思考哲理 (Philosophy) 、方法 / 步驟 (Methods / Steps ) 、與伴隨的工具 (Tools/Utilities) 。因為沒有任何兩家的流程，組織，策略目標是全然一樣的，因此怎樣才能從策略目標規劃到最后系統導入執行連貫一體，成功而有效地完成建置所依賴的才是合適的方法論。
目前各家 BPM 廠商所提出的生命周期不盡相同，乃是因為解決方案所面對的產業或應用領域不同，所以有了各自強調與專注的重點。例如， IBM HoloSofx 提出的是：建構 (Create) 、管理 (Manage) 、自動 (Automate) 、協同 (Collaborate) ； Howard Smith & Peter Fingar 在 『 BPM - The Third Wave 』一書所提出的是；建模 (Model) 、布署 (Deploy) 、與管理 (Manage) ； Italio 提出的是發掘 (Discovery) 、建模 (Modeling) 、支援 (Supporting) 、 Monitoring ( 監控 ) 、及 Improvement ( 改善 ) 。在此我會提出較為完整的流程步驟，但不見得每家 BPM 廠商的都符合，讀者可參考下圖－ BPM 生命周期。
圖一、 BPM 生命周期
·階段一、 流程發掘 (Discovery) :
要導入 BPM 第一步驟當然要先清楚知道現行流程的作業方式與狀況，尤其是流程內的信息流 (Message flow) 、事件流 (Event flow) 、或控制流 (Control flow) 。哪些流程可以自動化？哪些是人工流程？有哪些人參與？流程是在組織內部或外部被執行？ BPMS 在此步驟的主要特征是如何 自動找出系統的商業邏輯 。通常企業會聘請外部顧問師或領域專家來協助輔導，這個動作有人稱為 流程評估 (BPA, Business Process Assessment) ，評估范圍可能涵蓋策略與管理目標與流程的連結。同時企業也會配合導入一些管理的主題而作 流程再造 (BPR, Business Process Reengineering) ，例如評分計分卡 (BSC, Balance Score Card) 、六個標準差 (Six Sigma) 、或 ISO 9000 品質管理系統。
· 階段二、 流程設計 (Design) ：
此階段是一個包含四幾個步驟的反復式的小循環 (Iterative mini-cycle) ：建模 (Modeling) 、 ( 分析 Analyzing) 、模擬 (Simulation) 、重構 (Redesigning) 流程。如前所述，面對外部的競爭壓力與商機，為了讓企業可以快速重構流程， 因此一些細致的流程變革 (Fine-grained process change) 只需利用此階段的步驟就能作出實時的反應。
流程 建模 所運用的工具稱作 Process Designer 通常包含三個模塊：組織 (Organization Chart) 、流程圖 (Activity Diagram) 、與窗體 (e-Form) 設計工具。它們分別對應流程中三個最重要的元素：人、活動與文件 ( 有興趣的讀者可參閱 Process Modeling Conceptual Framework 有關的資料，后續容我在適當機會再做介紹 ) 。建模之后可以作執行動作前的 分析與仿真 來驗證設計的流程是否正確合適或最佳化；此外它能還提供現行流程可能遇到的瓶頸信息，以避免執行后才發現問題進而導致很大的營運損失。如果分析模擬出來的結果并不滿意，可以反復 重構 流程直到產出滿意的結果。分析指的是從流程定義的語意與理論上的推論分析，仿真則可設定機率變量與行為假設讓系統自動跑出期望值或變異差數據，有些則僅提供自動執行 (Animation) 或手動逐步執行以觀測流程行為。
此階段 BPMS 的主要特征是 圖形化的接口 ，讓非 IT 背景的用戶可藉由拖曳方式也能輕松組裝或分解流程；此外運用流程資產 (Process assets) 的觀念，讓流程定義隱含業界的最佳實務 (Best practices) 或流程樣版 (Process Pattern) ，并且儲存于流程倉儲 (Process Repository) 以供隨時再利用 (reuse) 。
· 階段三、流程執行 (Execution) ：
意指新上線的流程能被參與者順利執行完成。負責控制執行的模塊可稱為工作流程引擎 (Workflow Engine) 或流程服務器 (Process Server) 。在此階段 BPMS 主要的訴求是分布式交易 (Distributed transaction) 的管理，因為這些交易可能是復雜度高的跨巢狀流程 (Nested process) 而且交織著新舊系統，甚至將既有的應用系統當成流程組件來執行。至于流程的執行者通常多是應用系統，可以不用人的參與 (human intervention) 而自動執行，也就是一般所稱 流程自動化 (BPA, Business Process Automation) 。
此外，排程工具 (Scheduler) 可以應用來設定自動啟動流程的時間與周期頻率。有些 BPMS 的產品會提供規則引擎 (Rule Engine) 來負責商業規則判別與推理。此階段另一個重要的特點就是在不用技術人員的參與下，依然可以讓流程用戶自行編輯與修改商業邏輯。例如，代理人的指派規則通常相當復雜，背后就需要有 Rule-based 的機制來支持。
流程布署 (Deployment) ：意指將設計好的流程推出上線讓所有參與者 (Participant ，可能是人，應用系統，或其它流程 ) 來執行。這個步驟的主要特征就是能以最小的力氣﹙ effort ﹚達成運算資源 (Computing Resource) 與組織人員的結合 (binding) ，如事先整合應用系統組件 (Application components) 。
與人互動 (Interaction) ：在流程的執行中很重要的就是與人的互動。并非所有流程都可以自動化，所以 BPMS 讓人能管理自動流程與人工流程之間的接口。負責與人互動的接口稱為工作項目的處理程序 (Workitem Handler) 。有時候流程接口本身也是一個流程，例如動態加會簽或在窗體輸入下一步流程的分派。過去 Workitem Handler 相當簡單，然而現在有傾向豐富化與細致化的趨勢。必要的時候還能讓用戶客制化或整合在不同系統的接口中。由于這個需求有快速提升的趨勢，所以各家廠商紛紛提出豐富且個人化的流程入口網站 (Personalized process Portal) 。
第四階段、管理維護 (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 系統架構 (System Architecture)
圖二、 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 的方式，實時地追蹤目前流程的進度或進行例外的處理以能做到修正或變動的因應。也就是說活動的監控對流程范例的執行提供了一個績效量測的準則。最后透過上述工具使流程作到實時的修正達到最佳化讓工作更有效率。
?