技術交流

企業流程管理新思維-BPM下一代資訊技術發展的藍圖(下)

鄭銘輝

• 本期導覽
• 技術交流

上個月電子報提到企業為何需要BPM與下一代IT藍圖需要採用BPM，本月更深入地闡述對BPM的定義及相關之標準。

國外對於 BPM 的定義

BPM is an IT-enabled management discipline, development rules that require organizations to shift to process-centric thinking and reduce reliance on traditional and functional structure.

BPM enables business managers to abstract process and rules from underlying applications and infrastructure, and change it directly.

BPM enables organizations to manage complete revision cycle of processes, from design, to monitoring and optimization.

企業流程管理將IT融入管理的原則，系統的開發以流程導向（ process-centric ）為出發點，降低對傳統與功能性的依賴。

註：流程導向(Process-centric) 為在建構系統時，首先了解特定工作的流程要求，並將其切割成服務界面(包括輸入與輸出資料格式)，如此其他的發展者就可以依據服務界面開發(或選擇) 合適的元件來完成工作

企業流程管理讓企業的管理者將處理元件與規則由底層的應用系統或IT的架構中抽離出來，並且可直接修改。

企業流程管理讓組織可以管理整個流程的生命周期，包括設計、監控與最佳化。

什麼是BPM(Business Process Management)？

BPM就是把所有的要素和所有業務流程中涉及的資源包括人與應用系統都連接起來，以保證工作流程無縫執行，並更有效率。這種技術把業務流程中的控制部分提取到業務流程層，這樣它就可以重新建模、重複使用，從而協調所有的人員、應用程式和系統元件已達成更高效率的工作。

因此一個BPM-Enabled 的應用系統不僅緊是以BPM平台來開發應用系統，而是將應用系統切割為一個個的服務元件，再以BPM的平台來整合或串連這些元件，在一個企業中跨應用系統來說，BPM 可應用於系統與系統間，服務或程序的整合，在單一應用系統內部，亦可用來整合內部的服務元件。

BPM 相關標準

BPM 的成功的原因有兩個主要因素：以Web Service 與XML 所建構的SOA (Service-Oriented Architecture)及Internet的興起。Web Service 與XML 解決了系統整合間的資料交換問題，Internet 解決了通訊的問題。

在企業流程的描述上主要的標準分為兩方面：流程描述的圖型、流程描述的語言。

流程描述的圖示

BPMN(Business Process Modeling Notation)是BPMI（Business Process Management Initiative）這個組織以兩年多的時間制定出來，正式版1.0在2004年的5月發表的。

在此標準發表之前，流程的定義並沒有一致的標準，而是由各流程模型設計公司如（ARIS）IDS Sheer、ProActivity、Popkin、Casewise、MEGA等單位自行定義。

除此之外亦常引用一些相關圖型來表示如UML中的ActivityDiagram 、Activity-Decision Flow(ADF)圖、美國國防部的IDEF等。

BPMN 是目前被應用在以標準的圖示來描述企業流程規格極為重要的標準。

流程描述語言

WfMC 的XPDL

WfMC 為一個工作流程的組織，其制定了一套流程的描述標準XPDL(XML process Definition Language)，XPDL 較著重的在於人員間工作協調的描述。

BPEL(Business Process Execution Language)

在流程描述的語言上，因為與產品的規格息息相關，因此也就出現了百家爭鳴的情形，包括Microsoft提出的XLANG(XML business process LAN Guage)、IBM提出的WSFL(Web ServicesFlow Language)、HP提出了WSCL(webservices conversation Language)，BPEL 是由(XLANG與WSFL)結合後產生，交由OASIS組織訂定為標準，而WSCL則演化成為WS choreography 由W3C訂定為標準。

除此之外，工作流程組織WFMC也訂定了一套標準XPDL(XML process Definition Language)，BPM組織BPMI也訂定了BPML(Business Process Modeling Language)。

其中BPEL是目前最為業界所接受使用的流程執行標準，BPEL採用XML來描述企業流程，其扮演著服務之間合作的協調者，描述了流程控制如分支、迴圈、平行處理、訊息處理及關連性、例外處理等。

但由於BPEL過度著重於應用系統服務間的協同作業，在人員整合明顯不足。因此有業者提出包括BPEL4People等的標準來補強。

Model-Driven vs Code-Driven

由BPM 的標準，我們可以發現一個完整的企業流程的介面需要包含流程描述的圖示與流程描述語言兩部份。

流程描述的圖示是一個人與人溝通的介面，但電腦主機並無法直接讀取圖形，因此需轉換為流程描述的語言，作為人與機器溝通的介面。

因此不論是否採用那一種公開BPM的標準或自定的標準，此兩部份是缺一不可的，但是是否有這兩部份就可以達到一個BPM 管理平台的介面基本要求呢？這個議題可以由另一層次來討論：流程的引擎是否可以直接執行流程描述語言或者是需要經過Complier & Link 後才可以執行，這也衍生出企業流程管理系統中所謂的模型驅動(Model-Driven) 及程式驅動(Code-Driven)兩種模式。

如果流程的引擎無法直接讀取流程的描述語言，則必需將流程描述語言轉換為電腦可以執行的0與 1的執行檔，此時因為執行的程序已經變成固定的程式碼，因此就無法彈性的變動及動態的調整，舉個例來說當一個主流程中包含了不同的子流程，在Code-Generation Model 中必將所有會發生的狀況都包含在編譯完成的執行檔中，任何的改變都需要重新編譯程式。

流程引擎如果可以執行流程描述語言(通常為XML)，則當流程調整或動態改變時只需要調整流程描述語言，無需經過編譯及聯結的程序就可以執行。一個主流程若包含子流程，子流程可視完單一的流程，獨立的啟動，因此可以動態的決定所要呼叫的子流程。

換言之Model-Driven 或Code-Driven 將決定企業中的人員參與規劃的程度，在一個Code-Driven 的流程平台中，規劃人員(IT或Business User)只能作簡單的流程繪製之後需交由程式設計人員將其轉換為執行檔，任何流程的調整也需要程式設計人員參與。

如果採用Model-Driven 流程平台，程式設計人員負責提供流程中所需的元件，由規劃人員(IT或Business User)將其組裝為完整的流程，直接可佈署及上線執行，規劃人員可以將流程分為不同的模組，只要完成其中的一部份就可以分段開發、測試，可提高管理人員對整個開發程序的掌控，而不像Code-Driven的Model,系統規劃人員規劃完成交給開發人員後，只能等開發人員完整的作完才能交回規劃人員，因此採用Model-Driven 的流程管理平台將更能符合企業流程管理的本質。

一個Code-Driven 的流程中，任何元件的改變都需要將重新編譯執行檔，Model-Driven 因為流程不需編譯(需要編譯的是流程元件)，因此只需修改元件，重新佈署即可。

一般的BPM平台中都會包含版本的控管，已經啟動的流程會執行舊的版本，新啟動的流程會執行新的版本，在Code-Driven的流程引擎中，因為流程已編譯成固定的執行檔，因此無法將已啟動的舊流程轉換為新流程，在Model-Driven的模式中，因為流程是以Script描述，因此只要透過簡單的對應設定就可以將舊的流程轉為新的流程繼續執行。

Code-Driven 唯一勝過Model-Driven 的部份是在於大量交易的效能，不過在執行效能的議題上應該討論的是合理的效能，例如每天啟動流程的數量是否足以滿足企業所需，而非一味追求高效能，而忽略了流程的彈性與變動性的重要。