转自 http://www.iem.mit.edu.tw/~grad9114/bb/viewtopic.php?p=124
BPM概念與BPMS之相關技術是架構在Web Services/SOA之基礎上，未來不僅會改造企業建構IT 系統的方法，也同時改變企業營運模式，或稱商業流程的執行方式。對廠商而言，誰能主導流程定義與執行的相關標準誰就是市場的贏家。
本篇將要探討，目前有哪些標準與主導的廠商陣營？這些廠商陣營如何既結盟又競爭？又誰能一統江湖而成市場最大贏家？
BPM與SOA
BPM藉由明確表式的流程定義將耦合鬆散的一群獨立服務串聯成新的商業流程，並讓不同的BPMS能相互溝通與執行企業流程。因此標準流程定義扮演著BPMS技術中的核心角色。
流程定義語言是一種正規(Formal)語言，可以將企業各種流程表示成一種可執行流程(Executable Process)形式的正規模型。
由於BPM擴展了Web Services的應用，所以能乘駕在巨大的Web Services發展浪潮御風而上。BPM的相關標準大都用來定義BPM和Web Service如何整合與部署以達成企業任務。多家軟體大廠和標準組織都架構在Web Services相關標準的基礎上，也就是說，這些標準都延伸了XML、SOAP、WSDL、和UDDI幾項技術規格。
目前冒出的BPM相關標準為數不少，大家較為熟悉的有WfMC's XPDL (XML-based Process Definition Language) 、BPMI's BPML (Business Process Modeling Language) 、還有ebXML's BPSS (Business Process Specification Schema) 。除此之外，還有由廠商結盟的陣營，如BEA、 Microsoft、與IBM聯合制定的BPEL4WS (Business Process Execution Language for Web Services，簡稱BPEL)，以及由Sun Microsystems, SAP, Oracle, Italio與其他公司共同制定的WSCI (Web Service Choreography Interface，網路服務編排介面) 。
這些標準都是利用活動(Activity)作為流程定義之基本元件，每一個活動伴隨一個實體相關資料 (Instant-Relevant Data)，作為流程傳遞的邏輯(Routing Logic)評估條件，在BPML 稱property，XPDL稱 Workflow-relevant data， BPEL 稱 Container。
XPDL標準著重在工作分配(Distribution)的相關議題，例如如何指定活動執行所須的資源與應用程式。BPML 標準著重在定義Web Service的重要議題，如支援交易(Transactions) 與例外處理，定義特定訊息交換與事件處置的活動型態。BPEL標準的重點與BPML相類似。WSCI 標準著重在Web Service的Choreography，像是服務介面的行為。BPSS以ebXML 建議的UMM (UN/CEFACT Modeling Methodology, 模型化方法論) 為基礎，以便支援在企業間以各種交易行為(Business Transaction)組合成所謂的企業協同(Business Collaboration) 。
標準：群雄稱霸 西瓜偎大邊
IT產業中，大者恆大是贏得業界標準地位的不變定律。百家爭鳴的戰國時代中，大家都希望成為產業的主流標準，因此為了獲得最後勝利，小型的標準組織會漸漸去依附大的國際標準組織並爭取這些組織的認可。透過大組織的力量將小組織建置的標準推行全世界，將可吸引更多的使用者、獨霸市場形成國際認可標準，而不再僅是規格。
例如，微軟與IBM各自推出流程標準XLANG與WSFL (Web Service Flow Language)。但在2002年兩家大廠合作共同推出新規格BPEL4WS，並且向OASIS 標準組織提出提案報告，最後也獲得OASIS認可的標準。Sun Micro及Oracle合作的廠商陣營為了推動WSCI，將這個規格標準送往W3C，並都參加了W3C 的Choreography工作小組。同時BPMI組織也向正在研究企業流程標準的OMG提案，希望OMG直接採納它們制定的標準或是與OMG即將訂出的標準可以相對照。
從許多跡象顯示，目前顯然是BPEL較佔上風。例如，今年WfMC在義大利舉行的技術大會中，與會廠商談論的聚焦從去年的BPMN (Business Process Modeling Notation by BPMI) 轉移到BPEL。今年SAP和Intalio在支援WSCI之外，也決定支援OASIS的BPEL。包括Siebel在內的20幾家廠商也計畫採納BPEL。此外，Oracle今年在Java One發表了以BPEL為基礎的流程模型化工具 (Modeling Tool) 以及工作流程自動化軟體。
多方壓寶？大和解？
同時我們也可以觀察到一些有趣的現象：廠商同時在不同的聯盟支援兩個不相容的的標準。所以，越來越多的的BPM產品都可以支援多個企業流程語言標準，以避免讓其產品在一群複雜且自成一派的標準中成為孤島。
不過這也不是無解問題，因為各陣營也出現大和解之勢，尋求標準間之互補性與互通性，讓差異減至最小，同時避免出現不相容的兩套標準。像是今年昇陽和甲骨文藉著參加OASIS BPEL的會議，試圖推動W3C工作小組和OASIS之間的合作，解決兩個重複的標準。甲骨文已經正式加入OASIS BPEL技術委員會，昇陽也有意加入技術委員會。IBM、Oracle、BEA、Sun Microsystems同為WfMC及BPMI會員，但IBM、BEA與微軟卻也積極推動BPEL。
到最後，哪一個BPM標準會勝出還很難說，雖然BPEL目前較具有冠軍相，不過我相信還需要一番較勁。
BPM標準涵蓋的範圍相當廣泛，所涵蓋的BPM生命週期也不盡相同。彼此之間有些重疊、又有些相關分類架
構，如何清楚瞭解這些標準用途、定位、與跟Web Service標準之關係？請見下回分解。
(2)
上次我們討論了BPM現在成為兵家必爭之地，但誰來一統江湖還說不一定。本期文章我想跟各位分享一下目前流程定義標準的內涵與涵蓋的範疇，這有助益於讀者瞭解BPM在技術面的基礎概念，可以說是BPM的心法。
標準範疇的界定主要是以BPM生命週期為基礎，在此我先將之簡化成設計(Design)、執行(Execution)、與管理(Management)三階段，完整步驟後續我會有專題介紹。要認識流程定義標準則先要瞭解他所處理的議題，而搞懂這些議題則有助於瞭解每種標準最擅長解決哪種任務，也就有助於讀者未來可以依照不同需求來選擇BPM廠商及系統。
流程符號 (Notation)：符號是溝通的基本元素，相信各位所知道流程圖不下數十種，如MicroSoft Visio 就提供非常多種類的流程圖，IBM Rational 's UML (Unified Modeling Language)也有提供Activity Diagram。倘若能統一且用一般人所熟悉的符號，則會讓溝通變得容易，製作工具的取得也會相對容易。
流程定義 (Definition)：怎麼去描述一串流程？怎麼讓不同軟體工具彼此間可以交換描述出來的定義？並且讓另一個軟體系統 (BPMS)去執行？例如，用MicroSoft Project 描述出來的專案開發流程，就不能被執行。所以流程定義的形式必須是正規(Formal)、嚴謹(Precise)、並且是可執行的(Executable)。
流程執行 (Execution)：怎麼讓一個流程可以自動執行？怎麼讓不同(廠牌)的BPMS系統可以互通？怎麼去呼叫應用系統？怎麼與人互動 (Human Interaction)？
流程管理 (Management)：怎麼知道流程狀態？有沒有一種像資料庫SQL一樣的流程查詢語言？因為這是追蹤(Tracking)、稽核(Auditing)、績效評量(Assessment) 等管理工作所涵蓋的基礎。
跨組織的流程 (又稱B2B)：如何跨越組織的界線知道、取讀、或執行外部的流程或稱服務？如何讓跨組織的流程能完整順利執行完畢？
不過就像我在上一篇提到的，各BPM陣營目前進入大和解階段，因此上述流程定義所涵蓋的範疇相當廣泛，沒有一個標準涵蓋所有的範疇，涵蓋的部分也不盡相同，彼此之間有些重疊、又有些相關。
在搞清楚以上的流程定義所談論的內涵之後，在此我藉由WfMC 技術委員會所提出的標準分類架構 (如下圖所示) ，讓讀者清楚瞭解這些標準用途、定位、與跟Web Service標準之關係 ，如此各位就可以拿來「按圖索驥」了。這個架構將各項標準以堆疊(Stack)的方式呈現，由上到下代表從概念模型設計(Model Design)到特定互通性(Interoperability)的協定(Protocols)、資料格式、與編碼，也就是反應著從抽象流程設計、具體流程執行、到訊息互動(Message Interaction)。例如，如果您的需求著重在應用系統間的流程互通性上，就可以選擇WfMC's Wf-XML的標準，因為它能透過HTTP協定及許多其他的傳送機制包括電子郵件、 直接TCP/IP連線及MOM(訊息導向中介軟體)來運作。本圖中，水平排列的四組分別用兩個參數來分類，一個是流程定義或流程執行階段，另一個是與內部流程或外部流程。從左到右分別為：內部流程定義(Internal Process Definition)、外部流程定義(External Process Definition) 、外部流程執行 (External Process Execution)、與內部流程執行(Internal Process Execution)。
流程定義(Process Definition)
在內部流程定義的標準，主要重點在支援不同軟體工具間的整合，如何讓軟體工具定義出來的流程交給另一個軟體環境來執行。而在外部流程定義的標準則重點在支援互通性(Interoperability)，也就是定義出流程規格如何讓兩個不同的BPMS互動交談。例如
OMG
's BPDM (Business Process Definition MetaModel)，它可讓流程定義來接受各家的流程符號，如UML或BPMN，並進一步對應到(Mapping) 到流程執行，例如 BPEL 或 J2EE。
從下往上看，最底層標準是Web Services的標準架構；接著是支援流程互通性語意(Semantics)的標準 ，例如：啟動，暫停，查詢等流程操作(Operation)；再來是支援E2E (End-to-End)流程間之模型化(Modeling)與服務編排(Choreography)的標準。其中Wf-XML是WfMC 所制訂的規格標準 (Interface 4 in Reference Model)，它是一個互通性介面，提供流程語意的框架(Framework)，可以在同一個服務編排中跨模型使用流程操作。例如啟動一個企業流程，當該流程有牽涉到人工部分，透過該工作引擎的管控，可以讓整個流程在經過一段時間後完成整個流程。
流程符號 (Process Notation)
在流程定義(左邊第一、二組)階段的上層標準有大家較熟悉的IBM's UML及BPMI's BPMN (Business Process Modeling Notation)。BPMN是一種概括性的符號(Comprehensive Notation)，目的是藉由標準化的圖形符號，讓企業流程模型變得容易交換。因為BPMN遵循傳統流程圖(Flow Chart)與泳道(Swim Lane)符號讓企業人士容易閱讀，同時BPMN提供對應的用BPEL定義之可執行建構(Executable Constructs)，藉此填補了企業流程的初始設計之格式與執行這些流程的語言格式間的技術缺口。實際運用上，使用者可以用一些簡單的畫圖工具所畫出BPMN 的結果，以一些大廠，像是IBM、Fuego、或Intalio 的工具讀進去，然後繼續使用大廠的工具開發，如用Microsoft Visio 2003畫流程圖，然後餵給 IBM's WBI Modeler繼續開發。
外部流程執行 (External Process Execution)
在外部流程執行(B2B)的標準，主要重點在支援挖掘(Discovery)外部可互通的服務 (Interoperability Service)、支援互通的流程綱要 (Interoperability Schema)、以及執行期間(Runtime)之流程互通性。一般 B2B 流程整合的作法，可分為兩種。一種為緊密耦合(Tightly Coupled)或稱程序導向(Procedure- Oriented)，另一種為鬆散耦合(Loosely Coupled)或稱服務導向(Service- Oriented)。前者比較適用於流程明確，且整個系統可集中權力控管的系統。後者如Wf-XML，透過 Web Services 的鬆散耦合特性與非同步的 XML 訊息傳遞機制，描述企業間的 B2B 工作流程。B2B 跨組織流程方面，Wf-XML往下層是整合Web Services 底下的 SOAP, WSDL, UDDI，往上層是與各產業的XML流程綱要 (Process Schema) 相互溝通，例如 Rosetta Net 的 PIP。例如我國電子化政府推動的e化共通平台(G2B2C)，為了串聯不同政府部門的服務，而運用了ebXML's註冊服務，而流程標準目前還在考慮中，如XPDL 或BPEL。
內部流程執行(Internal Process Execution)
在內部流程執行的標準，主要重點在提供共通框架 (Common Framework)以利支援流程執行之功能。最高層是支援流程模型與活動狀態(Activity Status)的符號，接著是支援稽核格式(Audit Format)以利稽核資料之收集，再來是支援執行期間的互動語法，如BPPQL (Business Process Query Language )以利流程狀態之查詢，最底層是支援執行期間的互動功能，如WfMC's WAPI。
圖一
(3)
BPM (Business Process Management) 不是個新名詞，但近年來BPM這個名詞、概念、或背後所隱含的系統，卻分從管理與IT(Information Technology)兩股趨勢匯流而成一股新的風潮，是管理與IT前所未見的大融合，以排山倒海之勢，風馳電掣般蔓延開來，儼然以下一個殺手級應用 (Killer Application) 之姿態出現。
這股風潮可由著名的研究機構與大師的報告與觀察窺見一斑：
Howard Smith 與 Peter Finger認為：「第三波BPM是重新定義企業未來五十年競爭優勢的突破性進展。」
Michael Hammer在Agenda (中文譯為《議題致勝》)一書中指出：「企業的競爭優勢不僅來自於策略，更來自於能實現策略的流程執行力。」
Delphi Group著名分析師Barry Murphy表示在未來的12個月內，有超過70% 的企業正在部署或評估BPM解決方案。
根據Gartner調查，到2005年之前至少有90% 的大型企業將在企業內運用BPM系統。
Forrester Research針對528家北美IT決策者做調查，發現到採用BPM的公司家數在大量增加，自2002年中起從11%上升至33% 的公司不是正在使用，不然就是正在計畫導入當今的BPM技術。根據市場熱烈反應，可預期在2006年以前會出現高達340億美金的BPM軟體市場大餅。
這樣一塊潛力十足的市場大餅當然吸引者許多來自各個不同領域的ISV (Independent Solution Provider) 廠商前仆後繼地加入BPM的戰場。廠商從EAI (Tibco) 或B2Bi (Biztalk)、工作流程管理 (Italio, Flowring)、入口網站 (Brovision)、系統平台(IBM, BEA) 、到資料庫伺服器 (Sybase, Oracle) 的大廠也加入戰局，並推出各以原來領域專長為主的BPM類似解決方案。這些軟體大廠為了能快速進入這個市場，積極進行了一連串併購Workflow/BPM廠商的動作，熱鬧非凡，例如IBM買了HoloSoftx (2002) 、 CrossWorlds 、及 Metamerge； Tibco分別在 1999年 2004分別買了Xerox Inconcert及Staffware；Oracle 今年六月買了 Collaxa； Adobe的Adobe Workflow Server的前身是JetForm公司的InTempo。
勢之所趨
這股風潮背景來自於企業e化，造成了企業內部有無數個自動化的孤島 (Island of Automation) 的結果。由於套裝軟體(Packages) 或解決方案彼此要能溝通與相互整合，不是有先天上的限制無法達成或是花費的代價太大，所以對企業來說讓這些資訊系統整合起來，就變成一個非常重要的需求。
目前普遍性的整合方式是從IT切入，透過資料層次(Data-Level)來整合，如透過共享資料庫，或者藉由應用程式介面(API, Application Programming Interface) 來溝通或存取資料，也可以透過EAI Solution進行系統間之資訊流整合，EAI可以讓系統與系統彼此透過傳遞訊息/資料來整合。
Web Services 則是BPM風潮的一個重要IT驅動力(Enabler)。它可以讓跨平台及跨語言的應用系統整合變得容易且可行。應用系統可以根據Web Services標準加上一層介面，包成一個服務元件而被其他的應用程式所呼叫來傳遞資訊。Web Services 也是實現SOA (Services-Oriented Architecture)的基礎。SOA是一個軟體整合框架(Integrated Framework)，讓處於各種平臺中的連結鬆散(Loosely Connected)的應用程式/元件，達成在異質環境中交換資料與流程的目的。Web Services/SOA 可以讓系統在應用程式的層次(Application-Level)上整合。
非僅IT
然而，若我們的期望是讓企業營運變得有彈性且能快速反應商業環境的變化，則只從資料或/且系統的層次整合是不夠的，因為通常企業的營運智識 (Working Knowledge)與商業邏輯(Business Logic)都寫死(Hard-wired)在這些IT系統裡。所以要讓企業可以彈性並快速的調整複雜多變的企業流程，就必須提升到流程的層次(Process-Level)上的整合。BPM Solution滿足了這需求，它 在SOA架構中，扮演著將這些服務串聯成商業流程的靈魂角色，讓彼此鬆散的服務整合成新服務，並視覺化(Visualization)整個流程/服務概觀。
相信現在沒有人會反對企業e化導入解決方案不可能只有資訊系統 (IT System) 建置導入而不牽涉到組織(Organization)與流程(Process) 的變革管理 (Change Management)。現在企業思維的是不僅在公司內部作讓流程自動化(Automation)或整合(Integration)，而是延伸到客戶、伙伴、還有供應商，也就是跨越組織界線，從組織的內部延伸到組織外部，將自身流程與其他企業的流程做整合。所以企業所需要的不僅是流程的整合，而進一步需可協調(Orchestration)各企業間的流程，考慮的不僅是流程中系統間溝通與互動(Interaction)，而更需要考慮系統與人，或人與人的溝通與互動。
這就是BPM的內涵：不僅是IT，更在商業流程。
BPM是一種在商業設計(Business Design)而非技術實作(Technical Implementation)的層次上的一種能力，能夠去挖掘(Discover)現有(As-Is)流程、設計(Design) 新的(To-be)流程、佈署(Deploy) 流程系統、自動執行(Execute)流程工作任務、 分析(Analysis)流程執行績效、等涵蓋一連串完整的流程生命週期 (Process Life Cycle)的流程步驟。
流程管理系統(BPM System) 的技術必須三個特徵：流程必須要有明確表式的流程定義，必須整合現有的應用系統，及整合與人協同互動(Collaboration)的工具。BPMS必須要能可靠地完成分散的流程交易(Process Transaction)及複雜的流程序列，可能數週、數月，甚至數年。BPMS可以讓企業透過流程轉化為營運智慧，經過不斷修正的流程進而最佳化，與即時產生有意義的資訊，讓企業以更快速、敏捷、彈性的方式，因應企業的需求而獲致最佳化的成果，成為隨需應變的新企業體。
目前各廠商所推出的BPM的類似解決方案，數量之多讓人目不暇給，有如戰國時代，百家爭鳴。猶如當初ERP (Enterprise Resources Planning) 初萌之際，原本提供企業資訊系統(Enterprise Information System)的廠商，一面在瞭解ERP定義、範疇、與內涵是什麼之際，同時紛紛自稱為ERP 供應商並提出類似的解決方案。
未來有沒有可能或誰能一統江湖？BPM有沒有可能成為下一個殺手級應用？BPMS該具有哪些功能？導入BPMS所期望的效益是什麼？我想會有很多有趣的議題值得探討的，我會在這個專欄接續地與大家分享這些議題。
