Windows LiveWindows Live™
 
 
James's profileJames の BlogPhotosBlogListsMore Tools Help

Blog
    11/21/2005

    7堂BPM迷你課程第4回 －站在企業至高點選擇最佳BPM

    7堂BPM迷你課程第4回 －站在企業至高點選擇最佳BPM
    文/iThome (記者) 2005-11-13



    微利時代的來臨，企業從過去強調爭取業務，到今日同時著重利潤。然而，遊戲規則變動快速，企業必須能在環境變遷時，快速反應以保有獲利，這些都促使IT的支援，站上前所未有的重要位置。

    然而，套裝式的軟體或從頭到腳自行開發的系統，轉身的彈性與速度只有越來越慢，無法跟上企業腳步。因此，講求創造敏捷而有彈性的流程企業，建構新一代企業IT架構的BPM思維因而順勢興起，越來越多的企業認知到BPM的重要性，從而思考導入BPM系統，IT系統的提供者也抓住這個機會，紛紛推出BPM的產品，面對花花而吸引人，卻不甚清楚的各項行銷術語，怎樣的BPM解決方案才是企業的最佳選擇呢？

    360度審視企業需求

    從過去從事BPM的服務經驗中，我深深覺得企業今日面對的挑戰，解決之道都在於各部門能否團隊合作，因為企業每個目標的達成，都不會侷限在單一部門；同樣的，跟流程有關的系統，就必須有支援跨部門運作的功能。因此，在建立選擇BPM解決方案的那一把尺時，要能站在企業的至高點，從點的需求，到線、面的需求，環視整個企業構面，才能建立最佳的評斷標準，選擇對企業最有利的BPM解決方案。比如說，當企業規模不大時，或許無紙化而彈性的辦公（OA）流程，就是企業最需要的解決方案，但是當考慮企業成長的3年或5年目標時，整合能力就可能是要素了。另外，當IT專案包含訂單管理等涉及跨部門的營運流程，要完成任務不僅需要整合如ERP等既有系統，如何在系統建立的過程中，讓各部門配合IT部門同時導入BPM的觀念，建立合作而不推諉的態度，反而是專案成敗的關鍵，那麼BPM導入服務就站上更重要的地位，產品就不是唯一要素了。

    如上所述，因企業的需求不同，對BPM解決方案的選擇，可能會從單純的BPM產品，到BPM的專業服務都有可能，而在BPM產品功能的選擇，又依企業需求可能侷限在支援單純的表單e化的OA流程，到複雜的結合表單、整合、和各式動態流程邏輯的支援，甚或同時須具有和商業夥伴或客戶供應商的B2B流程整合能力等各項系統功能。在專業服務方面，也可能需要從建置服務、IT架構規畫服務，流程顧問服務、BPM專案管理服務，到營運策略顧問服務等等。那麼怎樣規畫評核方式，才能選擇到最佳方案與長期合作夥伴呢？

    評核4重點，眼光要放遠

    1.廠商的核心競爭力

    越來越多廠商將產品包裝成BPM產品，但是定位不同，自然各有不同的強項。比如說，套裝產品由於訴求特定，自然以好用為主，不強調整合等各式需求的變化，自然也缺乏流程管理與整合功能的機制，因此多適用於表單為主的流程（如OA）。而以平臺為主的產品，強調的是開放，可以支援多樣而複雜的流程邏輯，以及各項整合管理的需求，甚至各種前端人機介面的主流技術如JSP、ASP等，讓企業建立資訊高速公路網，串聯各項資訊的來源與出路系統，雖然對各式企業IT系統，不管是ERP、CRM、SCM、Portal或自行客製的IT系統，都可將流程的一環加入，強化成為具有高度流程化的應用系統。

    此外，廠商的服務能力跟產品一樣，自然也有不同的定位。如發展套裝式產品的公司，自然就不會多專注在專案服務的效率與方法的提升，然而BPM的專案與企業每日的活動息息相關，可以小至部門內的單一流程或訴求單純的流程，也可以是大到跨部門的全企業營運流程，是由各部門內的流程在各式相關資訊下，串連起來服務同一企業目標而構成，自然所牽涉的技術能力和專案管理能力與經驗，以及產業知識與經驗的顧問服務深淺需求都不一樣，這在選擇長期的夥伴時，除了產品發展的支援外，是非常重要必須思考的項目。

    2.必要的產品功能

    在看長期的需求同時，立即的需要是必須兼顧的，因此對於當下立即需要的產品功能，必須加以釐清出來，尤其是不可或缺的功能，比如說公司使用者群很大，可預期系統是很繁忙的，且不容許中斷的，那麼支援容錯與平衡負載叢集的產品系統架構就是必須的。另外，如簡化IT的管理是公司的目標，那麼對於組織架構的單一管理機制就是必要的，BPM產品就必須具備與公司內的組織架構資料源，做即時性的組織整合能力，避免定時性的轉檔處理和未來組織資料到處有而可能衍生的管理問題。

    確定必要功能是產品選擇的重要基礎，千萬不要嘗試整理出一份完整的BPM產品功能表，尤其是參考各家廠商的產品功能資料，覺得各項功能我都可能需要，而提出涵蓋各家之長的需求表，因為如此一來，目標可能變得模糊不清，廠商也無法確實了解你公司的需求，當然就更無法就公司產品的發展目標上，提出最佳的說明與互動溝通。

    3.建置與維護的需求

    在各家廠商都能提出解決的方法滿足上述必要的需求時，另一個需要考慮的方向就是建置和維護的需求，畢竟以成本方向考量，都希望建置的方法要能與公司IT技術人才的培養Roadmap相符合，不需要倚賴產品特殊的建置語言來開發，畢竟現在的思維與過去只重Coding的方便性不同，如何能與企業內部IT架構發展，以及人才的培養能相呼應，為企業帶來最佳效益，是今日IT主管思考的方向。

    此外，維護的成本多倚賴在產品的所能支援的功能多寡與管理的機制是否健全有關，比如說在支援工作分派的邏輯上，或如流程的分支合流的邏輯上，如果產品有提供設定的方法來達成，或可以在流程圖上清楚呈現支合流的邏輯，自然維護上會輕鬆很多。以管理成本來看，如果在流程維護上的每一個問題都需要看程式碼才能解決的話，一方面當系統越來越多時，不可能有人能夠了解所有的程式碼，風險相對會增高之外，另一方面導入BPM系統將營運流程納入管理的「管理」訴求就蕩然無存了，那麼BPM系統所應帶來的長期效益也就無從發揮，充其量只是「另一個」頭疼的IT系統。

    4.以最複雜的流程為考量之選擇思維

    最後，不要忘了公司的獨特性，每一個成功的公司在不同的產業中之所以成功，在於公司營運流程的獨到之處，想一想公司導入ERP時的思維在哪裡，以SAP來說，如果只是導入SAP，那公司和其他同產業使用SAP的競爭者有何不同呢？公司之所以成功，是導入SAP時，背後所隱藏的流程管控思維，就是有與其他公司獨到之處，所以公司有獨特的競爭優勢。所以，導入BPM時也要思考到公司的獨特流程邏輯，只有當選擇的產品，即使是公司最複雜的流程邏輯需求都可支援時，那導入該系統可預見對公司的效益會是最大的。所以，即使眼前規劃的需求是以簡單的流程為起始點，也不要忘了下一步的可能目標，畢竟外在環境的步伐越來越快時，公司內部的步伐也只有更快，下一個需求的產生可能就是明天。

    作者介紹－劉海珊

    超義科技BPM流程管理專業服務處副總經理，台大資訊學士，美國CMU資訊網路碩士，曾任職於美國AT&T Bell Lab、Broadvision資深顧問等職。在SOA、Web Services及BPM專案顧問服務有豐富的實務經驗。
    12:59:41 PM | Add a comment | Permalink | View trackbacks (1) | Blog it | BPM

    7堂BPM迷你課程 第3 回－現代BPM架構及技術（下）

    7堂BPM迷你課程 第3 回－現代BPM架構及技術（下）
    文/iThome (記者) 2005-11-05

    BPMN與BPEL

    我們在上一期，談到一些Web Services技術及SOA架構。Web Services提供了一個以標準為基礎的介面協定，讓不同的系統、甚至不同的公司，都可以很容易的整合在一起，我們可以用各個系統所提供的服務組合成所需的系統或服務。這種堆積木的組合方式，正是SOA所要達到的目標，然而，有什麼標準來定義這樣的組合方式？

    一直以來，程式設計師很習慣於用程式語言來控制複雜的邏輯，用系統介面（API）來呼叫外界的程式；然而在SOA的架構下，服務成為了主體，複雜的邏輯被包含在服務中，或者被拆散成不同的服務。因此要建構一套系統，必須先找到或產生所需的相關服務，最後再用簡單的邏輯把這些服務串在一起。從前這樣的工作通常是用流程圖來設計，再請程式設計師把它轉換成程式語言，然而流程圖只適合用來做高階設計，不能表示平行處理、同步、事件等，因此專門表示流程示意圖的標準BPMN（Business Process Modeling Notation）應運而生。BPMN可以直接描述流程的執行細節，並且轉換成的流程執行語言（BPEL，Business Process Execution Language），或直接在流程管理系統（BPMS）上執行。

    什麼是BPMN

    BPMN是BPMI（Business Process Management Initiative）這個組織花了兩年多的時間所制定的。正式版1.0是在2004年5月發表。在此之前，流程設計的圖樣並沒有一個標準，而是由各流程模型設計公司，如IDS Sheer（ARIS）、ProActivity、Popkin、Casewise、MEGA等或顧問公司自行定義。此外，其他標準也常會定義一些流程相關的圖示，包括UML的Activity圖、ebXML的BPSS、Activity-Decision Flow（ADF）圖、IDEF等。這有點像物件導向設計在UML還沒有出現之前，百家爭鳴的情況。

    由於沒有一定的標記及共同的語言，使用者常需要花上一段時間才能了解不同產品所設計出的流程，造成使用上的困擾即進入障礙。有鑑於此，BPMI便發展出了BPMN，其主要的目的就是要讓所有的使用者都有一個共通的語言，從顧問分析師、流程設計師、企管經理到維護工程師都能很容易的溝通及了解。

    BPMN統一了流程圖的格式及各種圖形線條的意義。舉例來說，圓形記號代表事件（Event），其中細邊圓形表示起始流程事件，粗邊圓形表示結束流程。此外，和傳統的流程圖一樣，菱形代表流程控制，除了決定流程進行方向之外，也可以決定平行處理（fork）與結合（merge）。真正要執行的工作或服務（activity）則是用長方形來表示。這些工作也可以是另外一個流程，稱之為子流程。在線條上，除了連結流程節點的實線之外，還有連結其他物件如註解的虛線以及代表訊息流向的破折線。BPMN除了應用在系統及公司內部的流程設計外，也可以用來設計跨公司的公共流程（public process）以達到B2B整合。在這種設計圖中，就可以用訊息流向的線條把雙方的流程與訊息的傳遞表達的很清楚。除了流程設計之外，BPMN的另一個目標則是要拉近流程設計與執行的距離。因此BPMN定義了各個元件對應到BPEL的細節，可將設計的流程圖直接轉換成可執行的語言。

    什麼是BPEL

    了解流程設計圖示的標準後，讓我們來看看流程執行語言的標準。這部分的標準與BPMN正好相反，各個標準制定組織及大型軟體公司爭相訂定流程執行的標準，結果則是標準太多而讓人眼花撩亂、無所適從。其中與流程相關的標準包括了Microsoft提出的XLANG（XML business process LANGuage）、IBM提出的WSFL（Web Services Flow Language）、HP提出了WSCL（Web Services Conversation Language）。前兩者（XLANG與WSFL）結合後產生了BPEL，交由OASIS組織訂定為標準；而WSCL則演化成為WS choreography，由W3C訂定為標準。除此之外，工作流程組織WFMC也訂定了一套標準XPDL（XML Process Definition Language），而BPM組織BPMI也訂定了BPML（Business Process Modeling Language）。執行標準增加了互通性、重複使用性，減少開發人員學習的需求以及轉換成本。有了互通性，系統間才能互相溝通、了解，進而降低系統的轉換成本。由於各大廠的支持，BPEL是目前最為業界所接受使用的流程執行標準。

    BPEL扮演著服務之間合作的指揮者，描述了流程控制如分支、迴圈、平行處理、訊息處理及關連性、例外處理等。BPEL是一個用XML來描述企業流程的方法，把不同的Web Services連結在一起而產生新的解決方案。這樣的組合方式與從前用程式把服務串在一起的方式相比較，顯得更有彈性且更容易管理。使用者可以透過不同的組合方式快速改變或產生新的解決方案。不過由於BPEL過度著重於Web Services的協同作業，在人員整合及支援上明顯不足。因此有業者提出包括BPEL4People等標準來補強。

    從技術的角度來看，SOA架構以及Web Services是非常好的設計發明，運用了Internet網路標準、並勾勒出下一個世代的軟體架構。然而服務間協同運作的方法及標準則未提及。本文就流程設計及執行標準做了初步的探討，希望能藉由這些標準的訂定及成長，可以讓未來服務間的串接更容易，進而達到快速設計、即插即用的地步，讓SOA的架構能普及到各系統。

    《作者簡介》黃仕鎮

    超義科技總經理，BPM暨B2Bi研究團隊領導人，國立中央大學助理教授，NYU紐約大學碩士/博士。曾服務於美國AT&T貝爾實驗室，為AT&T研究中心物件導向設計概念委員會（Object Oriented Technology Committee）成員，致力協助AT&T內各研究發展計劃演進至物件導向式設計概念和Web-based N-tier系統架構，以增進系統運作能力和未來發展的彈性；專精於SOA、Web Services、BPMN、POA……等當代e-business技術架構。
    12:58:31 PM | Add a comment | Permalink | View trackbacks (4) | Blog it | BPM

    7堂BPM迷你課程 第2 回－現代BPM架構及技術（上）

    7堂BPM迷你課程 第2 回－現代BPM架構及技術（上）
    文/iThome (記者) 2005-11-04

    從SOA、Web Services到POA

    現代的BPM系統多採行服務導向架構（Service Oriented Architecture，SOA），以標準化的開放式架構（Standard based open architecture）為基礎，運用最先進的Web Services技術以達系統整合與分散式處理的目的。而SOA（服務導向架構）是什麼？為何SOA最近成了當紅的IT名詞？在BPM領域中是否有更佳的技術架構可取代SOA？為了讓讀者對SOA有通盤的了解，在介紹SOA之前，我們先簡短回顧一下軟體系統發展的歷史。

    40年前電腦剛萌芽的時候，一臺電腦得兩三個房間才裝得的下，軟體功能簡單、以數目運算為主，但它的運算能力尚不及現在的一臺手提電腦；在電晶體問世後，電腦的體積逐漸縮小，而運算能力也倍速增加，此時軟體開始變的越來越複雜，各式的電腦語言也如雨後春筍般的出現。為了更容易維護，設計師把程式切割成一塊塊的，稱之為程序或函數，每個程序或函數都有一個介面，可以被呼叫並傳入、傳出函數。然而這樣的分割是以程式的控制及運算為主，而資料仍是共用的，因此當電腦速度以每隔18個月倍增的速度下成長，而程式的大小複雜度也隨之成長，如何更模組化的設計程式，提升再利用率成為一大課題。此時OO（Object-Oriented，物件導向）的設計概念便應運而生。所謂的物件就是把資料與程序包成一個基本單位，如此一來在維護及重覆使用上，都以物件為基礎，不需要為了修改程式或資料結構而一行行的去尋找被波及的程式。

    1990年代，當網際網路蓬勃發展之後，程式的執行不再被局限於單一電腦上，而程式的架構也由client/server、3-tier演進到 n-tier MVC的架構，而各個複雜系統架構之間，所用到的程式物件數量往往達成千上萬個之多，要管理維護如此龐雜的系統只有運用類似物件導向的觀念，把更大塊的程式包裝成一個基本單元，並且制定一套標準以便透過網路來呼叫各個基本單元，這就是SOA的基本精神，而這些基本單元在SOA中便稱之為服務。

    何謂SOA

    要了解SOA首先得知道「服務」的意義。不同的系統對服務的定義與需求皆不盡相同，從功能面來看，服務可以是簡單的匯率換算到複雜的信用卡交易系統；從技術面來看，服務必須有公開的介面（API）及呼叫協定（protocol）。而服務導向架構則是一個以服務為基礎的分散式處理架構。它有三個缺一不可的構成要件：服務提供者、服務需求系統、及服務目錄。由SOA所組合的系統，本身是個需求者，透過服務目錄來找到可以滿足需求的服務提供者，並藉由公定的標準呼叫方式來對服務提出要求。舉例來說，一套可及時換算各地匯率的會計系統，它可以透過服務目錄來找到環境中的所有匯率服務，從而過濾出符合所需轉換貨幣的服務提供者，此時這套系統就可以透過標準的協定與服務提供找交談並呼叫服務，請注意服務需求者（會計系統）可能同時也是服務提供者，透過各式服務的組合來提供其他系統（如ERP）特定服務，因此服務可以像組合屋一樣，由小的服務組成大的服務，再用各式的服務組出一個完整的系統。

    SOA與Web Services

    其實早在SOA成為熱門話題之前，就已經有許多SOA的技術存在，從早期的RPC、CORBA、DCOM，到近期的RMI、web Services都是SOA的實現工具，除了這些比較完整架構的技術外，也有一些專注在資料交換的結構及協定的技術，我們稱之為服務基底架構（Service Based Architecture），如Rosetta Net等就是這類的代表，不過這些技術雖然行之有年，卻沒有受到大部分人的注意。主要的原因是因為這些技術有其侷限性，並且技術門檻太高，不容易上手。

    近年來網路科技快速發展，頻寬與速度皆快速成長，因此分散式處理的架構逐漸受到大家的注意，再加上網路標準如HTTP、XML等的應用已成熟，使得Web Services受到大家的注目，Web Services的長處在於它沒有侷限性，從PC到大型主機、從VB到Java都可以互通，並且它產生服務及使用服務的工具日益成熟，使得入門的困難度減低很多，再加上各主要軟體大廠的大力推廣，造成了流行。

    Web Services是以XML、HTTP為基礎，訂定了三個標準：SOAP、UDDI、WSDL。這三個標準分別定義了傳輸的協定，服務目錄所需的資訊，以服務及服務本身的描述。SOAP（Simple Object Access Protocol）規定資訊傳輸可透過internet 標準的HTTP或SMTP協定，並且資料的格式包括MIME及XML都有詳細規定，所以服務需求者可以產生一個SOAP的要求給服務提供者，而服務的結果也經由SOAP傳回給原需求者，可是需求者要找到提供者，就必須透過一個目錄來找到，就好像我們要透過104來找到電話號碼一樣。UDDI（Universal Description , Discovery and Integration）提供了讓服務提供者註冊各種服務的機制，使需求者能找到服務提供者及其資訊，包括了公司資料所提供的服務種類以及各個服務的資訊，服務的描述是透過WSDL（Web Services Description Language）來完成的，其中有定義了這個服務所提供的功能，類似API的概念，也描述了這些功能輸入輸出的資料型態。

    POA大有凌駕SOA之勢

    SOA的好處在於它提供了一個很好的架構來實現分散式的處理，服務可以很容易的Plug-n-play即插即用，當服務停止時，系統也可以透過服務目錄的搜尋，找到同種類的服務，達到Hot Swap（熱插拔）的效果。不過在實際上，工程師們常發現用SOA實作一個系統，並非一件易事。這主要是因為SOA強調服務導向，而我們在設計系統時，卻是著眼於完整的功能及其目標，舉例來說，每個公司的員工其實都是一個服務提供者，協助公司團隊完成某項任務，然而，從公司的角度來看，如何將這些員工組成一支堅強的戰鬥體，完成交付的任務與如何找到這些人是一樣重要的。而這個整合的動作，其實就是企業流程或作業流程（SOP），因此有人開始提出POA（流程導向架構）的概念，用流程來整合各個服務，而各個服務本身也可以是由流程串接各種功能而產生的，SOA專注於元件的溝通與管理，而POA則專注於如何用這些元件來做一些有意義的事。

    使用流程導向架構的好處在於：

    1.由於POA是建構於SOA之上，它也擁有SOA的好處如整合性高、模組化、再利用率高、及擴充彈性等。

    2.容易維護、提升彈性：由於流程可以透過圖形的方式表示，並且用拖拉的方式就可以修改，不像一般程式將商業的Logic及執行步驟埋藏在程式裡。

    3.快速建立：不同於SOA只是一個概念及一些協定，POA架構有BPM系統的支持，要設計一套POA的系統可以透過市面上現成的BPM系統快速實現。

    從軟體系統發展的歷史來看，當系統越來越複雜後，人們便開始想辦法增大基本元件，所以從每一行到程序到物件，現在則是把服務看做基本元件來簡化系統設計，在服務的相關協定標準化之後，未來將會產生「網路效應」--越來越多的服務出現，系統建置將不再從零開始，而會利用這些服務來快速產生，更多的服務需求因而產生，並開始良性循環。

    由於，21世紀BPM系統須能協助企業更敏捷、有效率地串連人、流程、系統運用及資訊，加速企業回應全球化經營環境的速度，因此未來系統開發會更著重於快速整合各種應用服務，此時POA將是最佳選擇。

    《作者簡介》黃仕鎮

    超義科技總經理，BPM暨B2Bi研究團隊領導人，國立中央大學助理教授，NYU紐約大學碩士/博士。曾服務於美國AT&T貝爾實驗室，為AT&T研究中心物件導向設計概念委員會（Object Oriented Technology Committee）成員，致力協助AT&T內各研究發展計劃演進至物件導向式設計概念和Web-based N-tier系統架構，以增進系統運作能力和未來發展的彈性；專精於SOA、Web Services、BPMN、POA……等當代e-business技術架構。
    12:57:55 PM | Add a comment | Permalink | Blog it | BPM

    7堂BPM迷你課程 第1回：當BPM遇上SOA

    7堂BPM迷你課程 第1回：當BPM遇上SOA
    文/iThome (記者) 2005-10-28



    現今IT部門正被企業期望著肩負起繼ERP之後更重要的任務，就是協助企業成為具有快速應變能力的流程企業。面對21世紀全球競爭、詭譎多變的時代，企業只有不斷的調整因應，才能「適者生存」，追求更進一步地成長。

    隨著企業成長，IT跟隨企業各階段發展的需求，亦步亦趨地擴充成長。其中不乏由現成的系統，或是客製化的系統所組成，經年累月，IT架構大多缺乏彈性，而且難以整合。然而，在市場前方衝鋒陷陣的指揮者，面對更多市場競爭，冀望IT能更快速地反應與支援，卻往往無法得到立即的奧援，因而，「慢」幾乎成為作戰部門對IT部門的一致評語。

    面對上述狀況，該如何規畫正確的企業IT執行策略？相信大家最近都聽到眾多冀望解決上述困境的IT新名詞，諸如SOA（Service- Oriented Architec-ture）、BPM（Business Process Management）、Web Services等。這些名詞在不同的行銷場合，可能因為解讀的不同，而被賦予不同的義涵，該如何釐清它們的定位？由過去幾年在BPM領域接觸客戶以及服務客戶的經驗，我想從BPM和SOA開始來說明，並探討Web Services、BPEL（Business Process Execution Language）、BPMN（Business Process Modeling Notation）等相關熱門名詞之間的關聯和定位，希望能協助讀者在下次參加完相關的研討會時，有收穫而不是困惑。

    SOA與BPM的發展思維

    近來IT界在中介平臺的發展，大致是從兩個角度下手：其一是由下而上的思維，從IT架構面著手，解決異質系統整合耗時耗力的問題，著重在改進EAI（Enterprise Application Integration）系統私有架構的限制，建構一個跨技術的分散式整合平臺，可快速將所需要的功能組合在一起，滿足應用面的需求，這方面的發展是以SOA獨領風騷。

    另一則是由上而下的思維，從經營管理面著手，開展至IT對達成經營目標的支援，著重在縮短業務（Business）面與IT面的落差，落實IT快速支援業務目標的目地，建立可分析、可快速調整流程以因應改變的管理機制。這一方面則以最近火熱的話題BPM為主。

    然而，雖然兩種取向的發展角度不同，但終極目標都是相同的。近來的發展，已有相輔相成、互相靠攏的趨勢。好比蓋房子，如果BPM好比是有設計圖的施工團隊，那SOA就是模組化的施工法，最終的目標都是要蓋一棟好房子，住得舒服的房子。

    SOA與Web Services密不可分的關係

    SOA在1990年代被提出之始，原意是在軟體設計的概念和整合性軟體的架構。因此，諸如CORBA、RMI、DCOM或甚至使用Socket的技術，都可以建立具有SOA架構的系統，但是在強調鬆散耦合和技術中立的新定義下，SOA已逐漸定位為是建立於標準網路運算技術之上的架構與設計概念了，目標則在將商務功能（Business Function）轉換成為於網路上的服務（Services）。

    當然，標準的網路運算技術，指的就是一系列從SOAP、WSDL、UDDI，以及衍生的各項涵蓋安全性、訊息可靠性、關聯性等的Web Services技術，如WS-Reliable Messaging和WS-Security等。Web Services於是成為是建構SOA的基本要件，目前一般探討SOA的資訊，也都與Web Services密不可分了。而從SOA向上的延伸，則在加上了訊息驗證和轉換、依內容為主的訊息派送、負載平衡，以及各項配置、部署，和監控的管理機制後，有了ESB（Enterprise Service Bus）的出現，超脫了概念、技術、架構的層次，成為超越過去EAI系統的新一代Business Integration Platform（商務整合平臺）。

    BPMN讓BPM更能充分發揮

    相反的，BPM則是著重在管理。而BPM系統則是由實現BPM的各項工具和流程引擎所組成。由於著重的是管理，強調的是循環式的流程改善，而不在一次的完美演出。因此，BPM的導入不僅在使用BPM系統建構所需要的流程系統，更重要的是導入的方法和顧問的服務。藉由讓企業的使用者端了解正確的BPM觀念，讓資訊部門IT和企業裏的使用者（Business User），共同肩負建立或改善流程系統的任務，同時建立部門間合作而不推諉的做事態度。

    因此，建立IT和企業使用者彼此共通的溝通語言，是BPM的重要任務。由BPMI（Business Process Management Initiative）組織所定義的BPMN（Business Process Management Notation）流程記號標準，著重在完善的圖示企業流程涵義，由於BPMN是根據流程圖（Flowcharting）的技術為基礎發展，因此Business User、Business Analysts和IT的Programmer都能很清楚明白的由流程圖來溝通，輕易地拉近IT和商務間溝通的落差。

    BPEL將是BPM和SOA的黏著劑

    不管是SOA或是BPM，在落實活動的互動，都需要指導執行的語言，BPEL（Business Process Execution Language）是Web Services技術興起後，IBM和Microsoft各自提出的WSFL和XLANG的合併產物，對BPM系統來說，BPEL提供了跨BPM流程引擎的共通流程執行語言，而BPEL立基於Web Services的基礎特性，讓導入BPM系統的企業，能很容易邁向建立SOA的IT架構。

    另一方面，對SOA平臺架構提供者而言，BPEL是組合各個服務的共通語言──組合各式服務成為新服務（Complex Service）。然而，由於WSFL和XLANG原先都是專注在流程自動化的標準，因此在目前衍生出來的BPEL，較忽略人員的工作流程（Human Workflow）的支援。因此，BPEL在強化SOA的執行方面有直接的效益，但在強調以BPEL為基礎的BPM系統，在組織（Organization）和工作指派（Job Assignment）的彈性上則非常不足；或為了補起Workflow的不足之處，而多在標準的BPEL定義之上增加私有的擴充（Proprietary Extension），讓BPEL原本跨流程引擎（Cross Process Engines）的好處反而無法實現。

    在5月剛結束的JavaOne活動中，也有幾場課程在講解我在本文中提到的各項IT名詞，從IT的角度解釋它們之間的關係，是JavaOne中最熱烈爆滿的場次之ㄧ，讓迷失在眾多名詞銀河中的IT工作者，得到較清楚的關聯解答。

    然而，回到企業IT部門的主管心中，下一步到底是要導入BPM，快速回應企業需求，拉近IT支援商務的落差呢？還是要整頓企業IT架構，先建構一個彈性的SOA環境？其實，以現在兩者的發展看來，導入的先後次序並不會影響未來兩者相互合作的緊密性，最重要的還是審視企業目標、部門目標和分析企業IT架構的異質複雜度後，排出企業目前最極需解決的問題優先順序，再從那裡下手吧。

    作者：李耀台
    超義科技董事長暨創辨人，NYU紐約大學碩士/博士。曾服務於美國AT&T貝爾實驗室，主導 Provisioning Process Management System for Data Networking Services的設計與研發。專精於企業所需的 e-business解決方案，在SOA、Web Services及BPM專案顧問服務有豐富的實務經驗。
    12:57:15 PM | Add a comment | Permalink | Blog it | BPM
    11/9/2005

    BPM：全新面貌的Workflow


    BPM：全新面貌的Workflow
    文/iThome (記者) 2005-11-04

    無所不包的BPM萬用指南

    這一陣子BPM這個詞出現的頻率很高，BPM是Business Process Modeling或Business Process Management的縮寫。所謂的BPM，就是利用標準化的圖形語言和XML，將業務程序（Business Process）塑造（Model）成為一套活動流程。

    BPM比Workflow具備更多特點

    你可以把BPM想成是Workflow，改稱BPM是因為Workflow一詞已經被用爛了，「勢必」得發明新的詞，來挽救已經破碎的形象。唉！名詞被過度吹噓濫用的後遺症。

    其實，BPM和Workflow概念雖然相近，但是並不能完全劃上等號。比起傳統的Workflow，BPM多了更多現代化的特色，例如：BPM具有可執行的概念，BPM是建構在Web Services以及SOA之上的（BPM程序就是一種Service），BPM的程序（process）之間可以互動，甚至不同公司的BPM程序也可以互動。

    一般來說，適合BPM的應用，通常具有下面的特色：程序導向、執行期長、過程的狀態會被保存、大部分的時間在等待事件觸發以進入下一個活動、會需要和其他系統（或人員）進行合作。詳細評估某項應用是否應該用BPM來實踐，相當重要。在不適當的應用中導入BPM，可能會遭致許多反效果。

    BPM所帶來的好處

    運用得當，BPM能帶來下列的好處：
    ● 將既有的業務程序予以制式化，並找出需要改進的地方。
    ● 運用自動化的機制，讓活動（activity）完成後自動進入另一個活動，時間耗費趨近0。甚至運用平行處理的方式，讓整個程序的進行時間大幅度地縮短。
    ● 增加生產力，減少人力需求。實際的例子證明，一家保險公司採用BPM之後裁員40%，但保單受理比率仍然增加。
    ● 具有彈性，允許人員介入，解決無法自動處理的部分。
    ● 簡化公司的規章制度。

    任何對BPM/Workflow有興趣的人都應該閱讀這本書。但是由於BPM本身就是相當複雜的知識，所以這本書的閱讀門檻很高，讀者必須具備下面的基礎知識：XML、Web Services、SOA、SQL、Java、UML、Eclipse、Visio。

    本書共有三部（part）十一章以及一個附錄。第一部（共四章）說明BPM的概念、架構、理論、設計模式、與編程技巧。第二部（共五章）詳細說明各種標準，包括BPEL、BPMI、BPML、BPMN、WfMC、WAPI、WPDL、WfXML、WSCI、WS-CDL、WSCL、BPDM、BPRI、BPSS、XLANG、WSFL。由於某些標準尚未成熟，而有些標準瀕臨死亡，作者會建議你將重點放在某幾個標準上，其他的則快速瀏覽過即可。

    第三部（共兩章）開發出兩個BPEL應用，第一個應用是保單受理程序，第二個應用是企業訊息發派中心。透過這個兩應用的開發過程，順便展示兩個工具的用法，一個是「Oracle BPEL程序管理員」（Oracle從Collaxa公司買來的BPM工具），另一個工具是ITpearl的Process Modeler（這是一套圖形的塑模工具）。

    BPM成功的法門

    BPM的概念很簡單，就是：設計出「業務程序」，將此業務程序交給一個具備EAI（企業應用整合）功能的「業務程序引擎」來執行。儘管概念簡單，但是實踐BPM的細節、標準、產品、方法卻相當繁瑣，很容易讓人迷失其中。透過這本書，作者告訴我們許多BPM的精華，包括了：
    ● 一個好的BPM架構必須盡可能的優雅，一開始的設計如果思慮不周密，就等於埋下失敗的種子。作者在第二章會介紹優雅的BPM架構方式。
    ● BPM的標準很多，作者建議我們採用OASIS的BPEL（Web Services）以及BPMI的BPMN（繪圖符號）。
    ● 設計BPM就和設計物件導向系統一樣，有許多設計模式可以採用。作者在第四章介紹了20個設計模式。
    如果你只需要一本BPM的書，目前最好的選擇就是這本《Essential Business Process Modeling》。

    《作者簡介》蔡學鏞

    清華大學資訊工程碩士，現為寰震科技技術經理、美商歐萊禮出版社顧問、臺灣微軟特約專欄作家。曾任華碩集團軟體工程師、元智大學資訊系講師。

    蔡學鏞曾擔任數個研討會講師（包括 JavaTwo、TechEd、資策會）。參與設計清華大學 Java VOD 系統，該系統並獲得第一屆 Java Cup 比賽校園組冠軍。參與設計 Java To .NET Migration，成為美國微軟十大成功案例之一。

    蔡學鏞著譯有數本 Java 書籍，並在臺灣和中國的雜誌開闢技術專欄，專長的語言為 C#、REBOL、Java、C/C++。他的電子郵件信箱 xy.cai@msa.hinet.net。
    2:04:26 PM | Add a comment | Permalink | Blog it | BPM
    6/6/2005

    快速建置與管理商業流程的機會來臨

    Microsoft .NET 技術代言人專欄： 快速建置與管理商業流程的機會來臨

    作者：林耀珍

    2004 年 8 月

    運用資訊技術整合跨功能部門的商業流程、提昇效率、降低成本，是資訊相關人員多年來努力的目標，許多企業成功導入作業自動化、ERP、供應鏈、商業智慧的專案，得到優越的成效，因為這些資訊系統的基礎建設齊備，加上資訊技術的進步，我們看到快速建置與管理商業流程的機會已經來臨。

    什麼是商業流程 (Business Process)

    商業流程是企業經過多重步驟的業務活動 (Activities) 提供客戶最終的產品與服務，其結果是產生營收，提供客戶滿意度，或加強品牌形象。這些企業活動有些是內部的作業，例如產品設計、人力資源調配、採購、製造、會計作業，有些則是外部活動，包括行銷，銷售、客戶服務，與供應商互動。許多內部的作業因為具有穩定的特質，早期就獲得良好的資訊系統支援，達到高度的自動化；外部作業則因為變化快速，例如 SCM 或 CRM，自動化難度較高，但也在近幾年逐漸導入成功；最後則有些關鍵活動必需員工親自處理，例如法務，商務協商、或直接的客戶服務。

    建置商業流程管理系統的效益

    商業流程管理 (BPM-Business Process management) 是企業定義與執行商業流程、並獲得最終結果的能力。BPM 相關活動是企業內知識工作者花費最多時間的工作項目，所以運用資訊技術建置商業流程管理系統不是創新的想法，其實我們已經做了多方面的努力，例如早期的作業自動化，整合資料庫讓不同的系統分享資料，連結不同的系統達到不同程度的企業系統整合，導入 SCM 連結供應商，提供 Call Center 或 Web Application 提供客戶多重管道與企業互動，建置商業智慧系統協助決策。隨著這些個別建設的齊備 (ERP, SCM, Web…) 與 BPM 技術的成熟，我們現在可以運用 BPM 建置高度自動化的 End-to-End 的商業流程，以提高營運績效。運用 BPM 系統建置商業流程與傳統開發系統的方式相比較，BPM 具有下列的優點：

    1. 商業流程導向而非 IT 導向，所以與商業目標直接相關，從提供跨部門作業的整合性與流暢性，提高整體流程的效率，並可運用 BPM 的追蹤與統計分析功能，即時取得商務營運資料，使企業可以快速回應外部的需求。
    2. 使用 Configuration 的方式設計系統，避開撰寫程式的冗長程序，所以可以快速設計 Business Process，與彈性調整 Business Roles & Policies。
    3. BPM整合企業現行的 ERP、CRM 等系統，保障既有的投資，並且擴充它們的效益。
    建置 BPM 資訊系統的步驟

    建置 BPM 資訊系統分為五個階段，我以 Microsoft BizTalk 當作解說範例，讓讀者對建置 BPM 有具體的感覺；

    第一個階段是負責制訂 BP 的人員分析現行流程，加入創新或改善的設計，設定流程規則 (Process Logic)，定義最佳的商業流程。這個階段使用 BizTalk 的 Orchestration Designer 設計 Process Flow，定義 Document Schema、規劃與外部系統溝通的連接埠型態。

    第二個階段是整合其他系統到 Process Flow，就是連結 Activity 到個別的應用系統 (例如 Order Processing，Procurement，Shipping，Invoicing)。我們必須區分 Process Logic 與 Application Logic，以維持調整的彈性。這個階段使用 BizTalk 的 Browser 定義連接埠，這些連接埠是外部系統 (例如 ERP) 溝通的管道。

    第三個階段是儘量提高自動化的程度，雖然個別應用系統已經自動化，但是穚接的介面工作常常是銜接不同部門、或個體 (客戶、或供應商)，所以傳統上需要人工協商與文書作業，這部分最好能够根據議定或合約設計 Business rules and policies，方能提高自動化程度，達到提昇效率的理想。這個階段使用 BizTalk 的 Business Rule Composer 定義商業流程的詞彙，Rules 及 Policies。

    第四個階段是設計使用者介面，加入 Workflow 功能以管控必須的人工作業，定義外部 Partners 的身份與 Agreement。這個階段使用 BizTalk 的 Business Activity Service 與 Human Workflow Service。

    第五個階段是在佈署與營運 BPM 系統後，監控 (Monitor) 系統的營運是否正常，並處理異常狀況 (Event handling)。例如供應商交貨品質不良，或客戶抱怨處理延遲等事故。檢閱分析報表，比較導入 BPM 系統前後重要的績效指標是否改善，例如同時期的訂單處理數量是否提昇，處理訂單到出貨完成的時間是否縮短。這個階段使用的工具是 BizTalk 的 Business Activity Monitor 與 Tracking 工具。

    建立導入 BPM 的基礎

    因為建置 BPM 需要連結不同的資料系統，雖然 BPM 工具通常包含連結各種系統的 Adapters，但為了解除連結的障礙，建議開發新系統時應該採用服務導向架構 (SOA)，提供 Message-Oriented 的服務介面，例如 Web Services。並及早採用 XML 技術，規劃統一的 Data Schema，為日後的流程整合奠定良好的基礎。

    結論

    因為軟硬體、網路的進步與價格的下降，使得 XML、Web Services、Security、Process Engine、Rules Engine 等技術已經逐漸普及，奠基在良好的 ERP、SCM 等現行系統的基礎上，導入 BPM 將是下一階段最重要的資訊化工作。

    作者簡介

    林耀珍為 Microsoft.NET 技術代言人，現任寰震科技 副總經理，歷任第三波資訊技術總監及育碁數位科技總經理。專長於資訊系統規劃及軟體開發技術，擁有 Microsoft MCSD/MCSE/MCDBA，Rational OOAD，Lotus Notes/Domino 等認證資格，並為 Microsoft.NET/Java J2EE/ 物件導向系統分析設計的資深講師及多家公民營機構的 e 化顧問。

    意見與支援

     您有任何問題、意見或建議嗎？您可以透過下列電子郵件與作者連絡：
     lyaochen@ms3.hinet.net

    2:13:54 PM | Add a comment | Permalink | Blog it | BPM
    12/20/2004

    BPM≠Workflow＋EAI (下)

    出處:Taiwna.CNET.com:企業應用:名家專欄:梁賓先(華苓科技 總經理)

    16/12/2004
    原文網址 : http://taiwan.cnet.com/enterprise/column/0,2000062893,20094981,00.htm

    在這篇文章中我會繼續將最後兩個階段介紹完，並把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的方式，即時地追蹤目前流程的進度或進行例外的處理以能做到修正或變動的因應。也就是說活動的監控對流程範例的執行提供了一個績效量測的準則。最後透過上述工具使流程作到即時的修正達到最佳化讓工作更有效率。


    • 1:05:26 PM | Add a comment | Permalink | Blog it | BPM

    BPM≠Workflow＋EAI (上)

    出處:Taiwna.CNET.com:企業應用:名家專欄:梁賓先(華苓科技 總經理)

    15/11/2004
    原文網址 : http://taiwan.cnet.com/enterprise/column/0,2000062893,20094201,00.htm

    在談完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的系統架構與各功能模組作個整理，讓讀者輕易瞭解，下回待續。

    • 1:04:31 PM | Add a comment | Permalink | Blog it | BPM

    BPM武功密笈

    出處:Taiwna.CNET.com:企業應用:名家專欄:梁賓先(華苓科技 總經理)

    1/11/2004
    原文網址 : http://taiwan.cnet.com/enterprise/column/0,2000062893,20093696,00.htm

    上次我們討論了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。


    圖一

    1:01:16 PM | Add a comment | Permalink | Blog it | BPM

    誰來一統BPM江湖？

    出處:Taiwna.CNET.com:企業應用:名家專欄:梁賓先(華苓科技 總經理)

    16/10/2004
    原文網址 : http://taiwan.cnet.com/enterprise/column/0,2000062893,20093333,00.htm

    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標準之關係？請見下回分解。


    12:59:25 PM | Add a comment | Permalink | Blog it | BPM

    BPM：下一代的殺手級應用？

    出處:Taiwna.CNET.com:企業應用:名家專欄:梁賓先(華苓科技 總經理)

    6/10/2004
    原文網址 : http://taiwan.cnet.com/enterprise/column/0,2000062893,20093041,00.htm

    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所期望的效益是什麼？我想會有很多有趣的議題值得探討的，我會在這個專欄接續地與大家分享這些議題。


    12:58:07 PM | Add a comment | Permalink | Blog it | BPM