BPM≠Workflow＋EAI (上)
cactus
1則回應
分享
梁賓先
2004/11/15 10:32:48
在談完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)。
礙於篇幅，下集我會繼續將最後兩個階段介紹完，並把BPMS的系統架構與各功能模組作個整理，讓讀者輕易瞭解，下回待續。
cactus
留下回應
分享
2004/12/16 11:42:00
在這篇文章中我會繼續將最後兩個階段介紹完，並把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 系統架構 (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的方式，即時地追蹤目前流程的進度或進行例外的處理以能做到修正或變動的因應。也就是說活動的監控對
流程範例的執行提供了一個績效量測的準則。最後透過上述工具使流程作到即時的修正達到最佳化讓工作更有效率。