本文原刊載于：iThome企業軟件技術應用專刊（2005年）
　　作者：華苓科技副總經理 楊基載

　　前言

　　BPM(企業流程管理，Business Process Management)技術 與 SOA (服務導向架構，Service Oriented Architecture)各自歷經多年的發展，至今成為廣為業界接受的技術架構。本文將從 BPM & SOA 的歷史演進開始，深入淺出描述各標準的發展過程與彼此的關系，讓讀者輕松了解其應用范圍與來龍去脈。另外，也將以相關標準組織的最新資料為基礎，介紹當前制定中的新技術標準以及其演進。

　　以流程為中心的管理思潮

　　BPM 的范疇涵蓋企業營運的各項構面，如研發、生產、行銷、業務、人事、財務等企業營運活動，甚至往上下游擴及供應商與經銷商，以及客戶端的客服活動。訴求是企業應以流程化的思考方向，串連原本各自獨立而未協調的營運活動，使串連后之營運活動成為具有步步加值效果的企業營運流程，并輔以各項管理手法使其落實運行，達成企業流程管理目標。

　　1990年麻省理工學院 Hammer、Champy，哈佛大學 Davenport 等人，相繼在學術刊物發表企業流程再造(Business Process Re-engineering)觀念。1993年 Hammer  與 Champy 繼續發表《企業再造》一書，強調 BPR 的重要性，以及 IT 技術在 BPR 過程的角色，使 BPR 成為當時的熱潮。1997年，Hammer 又發表《企業再造之后》，宣告了流程化組織的必然性與重要性，并且預言 BPM/BPR 將改變人的工作方式。

　　2003年，Smith 與 Fingar 發表《企業流程管理：第三波》，預言往后50年BPM仍將是企業經營的重要議題，也指出21世紀BPM的型態與新特征，并給予可行的教戰守則，更羅列數十個企業運行BPM的實際案例與經驗，讓推行BPM的藍圖更加具體，使本書成為當年企管領域的暢銷書，讓BPM的風潮持續不滅。

　　BPM的推行觀念的改變與進程

　　根據1993年《企業再造》一書的調查，當時企業推行 BPR/BPM 有高達5~7成的失敗率。因為這么高的失敗率，所以即使BPM是企業勢必要面對的議題，也讓他們把BPM的推展視為畏途，甚至抱持負面的看法。之后，整個BPM產業繼續歷經十幾年的學習經驗，與前仆后繼的推行案例，不斷從許多案例歸納關鍵的成功或失敗因素，讓推展BPM的藍圖逐漸浮現。在藍圖中，錯誤的作法逐步被修正，更多的BPM管理工具被界定(identified)出來而豐富了整個藍圖。眾人慢慢認同，一個成功的BPM推行，是由以下金三角共同構成：

• 明確而有共識的組織流程規范
• 成熟的BPM軟件系統架構與建置
• 企業主管與員工的認同與運行力

　　從變動幅度來看，以往革命性大刀闊斧的BPR(流程再造)口號，已轉變為溫和的BPM(流程管理)實踐。這種務實的作法，事實上是察覺到組織變革、流程思考企業文化的形成，需要一年到數年的時間；革命性的快速改變，若無充分的準備與良好管理體質，反而讓企業亂了原有的腳步。所以一步一腳印的務實作法，漸漸獲得認同。企業從核心BPM流程的落實與推行開始，逐步拓展到外圍系統與業務伙伴，將可降低失敗機率。

　　而從管理成熟度來看，過去企業推行BPM，多半以流程計算機化這種短程目標為主，卻忽略了BPM的終極目標在于「管理」，而非計算機技術，也非流程細節。所以高階經營決策的需求常常被忽略而缺乏規劃。而因為缺乏指導目標，在BPM的需求導引過程當中，企業員工常會無明確的指導目標，而以為工作流程計算機化就是把自己手邊的工作巨細靡遺計算機化，而模糊了BPM的管理焦點。當這些與終極BPM管理目標無關的軟件需求被列入計畫討論，不僅模糊焦點，也無形地墊高BPM的整體成本。

　　事實上，BPM的管理可以歸納為以下幾個可逐步提升的層次，從這些層次也可了解一般組織推行BPM的成長歷程：

• 混沌階段：沒有明確的企業流程定義。
• 明文定義：具有書面的企業流程定義或標準作業程序，但沒有根據正規的記號(notation)，因此規則也許含混不清。
• 驗證與共識形成：定義的企業流程，通過公司組織政策的驗證，如質量政策，市場策略，管理原則，并獲得高層決策通過，達成組織共識。
• 組織人員的流程準備：組織成員經過教育訓練，認同組織制定的企業流程，并且具備運行的能力，包含專業基本技能的養成，并習慣流程化、信息化的作業方式。
• 企業本身的流程準備度：現行的企業組織架構，若與流程化的思考方式沖突，則應及早準備組織架構的調整，特別是毫無章法的職務與部門階層架構(hierarchy)。良好的組織設置與權責劃分，可以使流程定義更為精簡易懂、便于遵循，也容易分析企業規則之間是否相互矛盾；同時可降低BPM軟件系統的開發成本。
• 采用標準的企業流程表示法：使用一致的標準記號與格式來表達企業流程的內容。這里的標準記號應該是廣被業界采用的格式，例如OMG在UML所定義的活動圖(activity diagram)、BPMI (現已并入OMG) 組織所定義的BPMN，以及OASIS組織的BPEL。當然，企業流程的內容確實相當復雜，單一標準記號或格是通常只能描述部分構面，所以仍會有些構面暫時沒有業界共同認可的記號或格式可供選用。
• 流程自動化：使用軟件系統落實企業流程的運行流程。包括使用流程定義工具來定義企業流程內容，以及使用工作流程管理系統(WfMS ? workflow management system)來運行定義的企業流程。
• 進度監管：企業流程的運行進度可以被監看(monitored)與追蹤管理。
• 流程集成：流程運行過程中，能進一步與其他內外部的流程互通，或者與既有應用系統(legacy system)交換資料，以延伸流程的觸角，發揮綜效。
• 流程績效評量：企業流程的運行效能可以被測量(measured)，并且透過公式計算，以報表呈現有意義的管理指針。
• 流程分析與仿真：持續搜集企業流程的運行資料，分析組織的流程運行瓶頸，并回饋到流程定義，調整業務的運行方式。另外，也根據歷史資料與預測參數，透過仿真分析試算，比較不同流程調整方式所獲得的改善程度。
• 智慧型流程環境：透過流程資料的資料采擷(data mining)，主動分析流程統計數據，并回饋至流程系統。舉例來說，在客服流程系統中，主動歸納顧客過去使用服務的頻率與分布狀況，歸納未來的趨勢與規律(pattern)，并根據現有流程環境的現況(如現有承接量，以及可動用的客服人力資源)，自動調度客服人力分配策略，或向資源管理者建議客服人力調度策略。

　　企業推展BPM不見得要立刻從IT工具的選擇開始，前期的充分準備可縮短軟件系統的分析時間。企業流程自動化之后，則有更多的管理輔助工具可供搭配，強化企業流程的運行績效，提升企業的BPM成熟度。企業決策主管則可從以上層次分析，清楚得知達成不同層次的BPM進程，所能獲得的管理效益，以及相對的BPM技術解決方案需求。

　　BPM的技術現況與趨勢

　　BPM的其中一個技術構面是流程，它的IT技術解決方案的來源可追溯到1970年代晚期的文檔傳閱(routing)應用系統，主要目的是讓商業文檔與圖象能在不同計算機間傳遞，使文檔能從輸入或掃描人員，傳遞到審核人員與其他角色。典型的應用流程包括保險公司的保單資料處理作業，或者銀行的融資申請與簽約作業。這些需求促成了工作流程(workflow)技術的崛起，而軟件業也開始把工作流程技術應用到這類應用系統，成為核心組件。

　　工作流程技術是中立的角色，隨著不同應用領域的興起而有不同的運用方式，在辦公室自動化、公文系統、研發專案管理、制程管理、品保系統，或者客戶服務系統等等，都可以查找工作流程技術扮演的重要角色。即便是面對企業管理領域被炒得火熱的BPR/BPM，或者在IT/Web Services領域被當成新興技術議題討論的Web Services Orchestration、Choreography與企業流程運行語言(BPEL－Business Process Execution Language) ，只要詳細分析其技術本質，仍不脫工作流程技術既有的范疇。這些當紅的企管或技術名詞，一旦底層抽離工作流程技術，就無法獨立存在。

　　然而，狹義的工作流程技術并不是推行BPM所需的IT技術的全部。早期工作流程技術與圖象掃描與辨識技術結合，造就了文檔圖象流程系統。近年，工作流程從BPM領域切入，成為解決方案的重要一環；狹義的工作流程技術，歷經多年匯流了多項技術元素，成為當代的BPM解決方案，主要特色如下：

• IT技術面：采用工作流程技術為主體，結合入口網站(Portal)、企業應用集成(EAI－Enterprise Application Integration)、報表與商業智慧(BI－Business Intelligent)工具、流程模型分析(process model analysis)、與仿真(simulation)技術。這些現成(COTS——commercial off-the-shelf)軟件組件結合運作，可大幅降低信息系統的建置成本、時程，以及開發風險。 
• 管理活動面：可提供策略地圖、平衡計分卡、六個標準差、TQM等管理活動的必要管理信息，搭配合適的管理決策工具呈現企業整體的BPM成效。
• 貼近特定產業的流程需求：每個產業都有其特有的企業經營模式與參考模型，如制造業、買賣業、醫療業、物流業等產業，都存在產業專屬的流程模型與標準。像是 RosettaNet 替電子商務交易的詢價、下單、交貨、付款等流程作業，制定了日常實際應用的參考模型；而供應鏈協會(Supply Chain Council)則在供應煉與物流領域，制定SCOR流程運作模型(Supply Chain Operation Reference)。若流程定義工具能夠直接提供這些參考模型的語意支持，或者提供現成可套用的流程樣板(template)，將可以減少開發這些特定產業應用所需的成本。
• 服務接取(access)面：解決方案能滿足不同的使用者，如習慣大量資料輸入作業的專業使用者、少量資料操作的一般使用者、偏重BPM績效報表的主管，或者行動裝置的使用者。也就是說，可提供不同的操作界面，如常規桌上型應用程序、Web Browser應用程序、PDA，或者Smart Phone等裝置，給參與BPM系統的各種人員使用。
• 交互情境面：BPM技術解決方案需同時兼顧「人對程序」、「人對人協同作業」，以及「程序對程序」等交互情境。

　　鑒往知來，BPM解決方案的風貌將持續納入更多的元素而顯得多樣化，不管是因應管理哲學的革新、應用情境的延伸，或者新技術的崛起，只要有道理，沒什么元素不可以納入的。雖然沒有一個獨立的BPM產品能同時滿足以上所有特色（事實上，企業BPM規劃者也不見得要貪心得一次全部用上），但企業BPM架構規劃者，仍可根據BPM導入步驟，按部就班先進行組織改革與訓練，然后根據管理需求與現有的IT解決方案，參考本文所述的各項BPM特點，逐一評估挑選合適的IT模塊，納入為自己企業量身打造的BPM運行藍圖。

　　由于BPM解決方案并不是一次到位的架設，而是持續多年的活動，因此整體BPM藍圖必須考慮分期開發，漸進導入的特性，建議BPM的IT規劃者應參考本文稍后所提的SOA架構當成藍圖的基礎。

　　PM與工作流程相關標準組織

　　想深層了解一個專業的產業發展，透過產業標準組織是一個不錯的方式。對技術底層感興趣的BPM技術人員來說，以下的列表可以作為探索的起點。

表一：現行BPM與工作流程技術標準一覽表

　　WfMC是比較專注于工作流程的組織，它的WfMC workflow reference model是最常被引用的工作流程管理系統的參考模型。雖然WfMC的工作小組數目較少，但因為起步較早，旗下的XPDL與WfXML標準，有相當多的工作流程廠商支持。WfMC替工作流程的技術發展奠定了早期的基礎，它界定了BPM與工作流程領域的大框架，也持續不斷的推廣BPM與工作流程，讓眾人清楚這個領域的體系與架構。

　　OASIS與OMG的技術小組數目比較多，工作焦點也不僅限于狹義的工作流程技術。因為涵蓋的范圍較廣，而且背后的支持廠商規模較大，所以整體影響力也較大。OASIS旗下的BPEL取自IBM、微軟等公司，而ebXML則是OASIS與UN/CEFACT這兩個組織共同成立的工作小組。OASIS藉由充沛的技術發展動能，為工作流程技術領域開拓更大的視野，在流程定義格式、流程運行層面，以及復雜的流程交互機制等領域，提供了寶貴的技術解決方案。

　　OMG在BPM領域掌握了標準記號(notation)，包含UML，以及從BPMI并進來的BPMN。同時，OMG也積極以塑模(model)的角度，切入工作流程定義的其他構面，如共通模型表示法BPDM、流程語意BSBR、組織架構OSM、業務規則BRM等等。OMG的強項之一就是在塑模(model)技術，它的UML廣受軟件領域接受；在BPM與工作流程的領域，OMG持續發展BPMN與等其他BPM各構面的塑模技術，未來將使BPM的其他構面(如業務規則，或組織架構)也能使用像UML或BPMN這種等級的表示記號來進行塑模，讓復雜企業流程的塑模工作更加容易而清楚明確。

　　W3C的強項在于Web領域，HTTP是最知名的代表作。而XML與Web Services是BPM在SOA領域的基礎建設。其它相關的BPM技術，如WS-CAF, WS-RM, WS-CDL等等，都奠基于W3C的Web Services技術。

　　OAGi、RosettaNet，以及Supply Chain Council，則是特定產業領域的代表。它們的貢獻在于替特定產業界定共通的BPM運作規范，也就是說，定義屬于他們產業特色的應用流程參考模型與共通的術語，讓這個特定產業在推展BPM時，就有基本的需求大綱與基礎架構，也讓同產業體系內的廠商可以透過共通的產業模型與共通術語溝通，避免不同BPM應用系統之間生成各自為政而無法互通的障礙。如同前文所述，RosettaNet在電子商務領域已經廣為人知，SCOR模型則在于物流領域。雖然OAGi在國內的能見度沒有 RosettaNet高，但它涵蓋的范圍相當深遠，號稱涵蓋電子商務、制造、物流、航太、汽車、醫藥、零售、能源等32種產業。以OAGi 9.0版為例，就涵蓋61種流程情境(scenario definitions，像是訂單管理、應收帳款、供應鏈集成、銷售管理、客戶服務)與434種商業文檔(BODs, 像是訂貨單、維修單、撿貨單、零件物料列表等，在流程當中傳遞的文檔)的正規定義。

　　表一列出的各項技術標準，是以標準組織為分類依據，我們再以其他觀點來呈現其中幾個重要技術標準，以便讀者能夠更清楚了解這些標準的定位。

表二：依功能分類的BPM/工作流程技術標準一覽表

圖一: WfMC技術小組提供的工作流程相關標準堆棧圖，2003年版本

　　服務導向的企業

　　過去幾十年間，企業經營的焦點隨著市場趨勢而演化，60年代談的是提升量產，70年代談的是降低成本，80年代談的是提升質量，90年代談的是產品推出速度，而跨入21世紀，談的是如何給客戶更多樣的服務。不管重心怎么改變，在21世紀之前，改善的重心仍落在產品實體；直到21世紀，重心已開始從產品延伸到購買產品的顧客，強調顧客是怎么樣獲得產品與服務。

表三：各年代的企業經營管理重心

　　為了提供多樣化的服務，許多企業活動將被解構后再重組為新的營運模式，而這代表位居幕后支持的IT技術，必須能迅速配合這樣的營運模式改變。也就是說，所有的IT技術與信息系統，都能夠像變形蟲一樣，隨時解構后再重組，在短時間內提供新營運模式所需的信息服務，這包括企業后臺營運所需的信息系統，以及面對客戶所需的前臺服務界面。

　　在十倍速的時代，企業無法等待。常規為了新營運模式而大規模更改 (而非重組) 信息系統的方式，過于牛步化無法滿足要求。下一節提到的SOA架構，替服務導向的企業，提供了很好的解答。

　　天生一對的企業流程管理(BPM)與服務導向架構(SOA)

　　SOA的IT技術本質單純而不難理解，個別的技術元素分別理解還算容易。對于SOA，大家聯想到的就是Web Services，談到Web Services，我們就直接脫口而出：WSDL、UDDI，以及SOAP，然后就是一系列的WS-＊的技術標準。對很多人來說，只了解個別技術單元，并無法領會到SOA世界的美好。就好像只看得到調色盤的每個顏色，卻看不到美麗動人的畫作。所以，讓我們先把無趣的技術名詞擺一邊，這無助于我們了解SOA的美好世界。

　　首先，我們需先認識SOA世界里的企業流程運作方式，以及SOA的技術元素可以互相彼此串接而形成豐富的生態；如此，就可知道為什么BPM與SOA是天生一對——SOA 架構總存在美妙的答案來滿足BPM變化多端的環境。

　　一般來說，真實世界的BPM，具有以下的IT需求特征：

1. 它的運作是分布式的：多數企業流程都是由多個參與者共同運行，參與者可能來自不同辦公室，甚至不同的地域區域，打破部門藩籬，甚至跨越公司的疆界；因此，跨因特網環境的應用系統支持，以及網絡環境下的安全性，都必須列入考量。
2. 它可以進行工作協調與應用程序集成：大部分的企業流程并不只是運行單一業務功能，而是多個業務功能互相協調后的成果；因此，原本獨立支持某項業務運作的應用系統，也必須跟其他業務的應用系統相互集成。
3. 它是動態的系統：企業流程中的各項元素經常動態改變。工作串連方式會隨著環境改變、人員角色扮演會異動，工作的運行地點也會改變。因此，BPM環境中的應用程序模塊，必須演化成快速適應變動的動態系統，可以輕易透過設置或配置的改變行為模式，甚至調整運行地點，以因應企業流程的變動。
4. 它的構成元素種類繁多而復雜：BPM系統內含分布于各模塊的企業邏輯與規則、各種不同安裝與監管模式的應用模塊，以及眾多模塊之間的串聯與相依關系設置。因此，BPM環境中的軟件模塊，需要讓模塊變得可以被BPM配置機制管理，這包含模塊的啟用停用、健康狀態回報，以及系統安全政策，都應有一致的管理方式與技術標準。如此，整個復雜的BPM環境運作才可列入掌握而不致失控。
5. 它可以漸進式地成長：企業可以從最簡單的BPM活動開始著手，再演進到成熟復雜的BPM系統；因此，整個系統架構必須能提供清楚的進步藍圖，允許企業按部就班投入IT資源，并逐漸提升BPM成熟度來運行BPM。

　　以上五個特征，剛好可用來陪同我們探索SOA的技術世界。

　　針對特征一，SOA技術架構可提供安全的網絡傳輸與運行環境。主要技術有二：一是軟件模塊互相通訊時，所需的保密需求，這可由WS-Security來達成。另一個則是組織成員在環境中的權限控管方式，這可在SOA架構內，采用LDAP、集成單一帳號登錄、PKI架構與數位簽章等機制來配合。

　　第二個特征引發的議題是SOA工作協調與應用系統集成。常規應用模塊在SOA的世界里，可以采用SOA規定的服務界面(Services Interfaces)對外開放模塊的功能。應用模塊之間，透過SOA的服務界面標準互傳資料，就是最簡單的Web Services應用案例。此機制的主要意義在于：所有SOA內的應用模塊，只要提供SOA的標準服務界面，就可以不受開發語言限制，互相調用或傳遞資料。這里的服務界面，講的就是WSDL(Web Service Description Language)；而SOAP(Simple Object Access Protocol)則是規定應用模塊之間互相調用或互傳資料時的封包格式。至于WSDL或SOAP的內容與格式應該長怎樣，大部分技術人員可以讓中介軟件或者EAI系統代勞，透過Service Adaptor直接把常規應用模塊包成Web Services模塊，并不需煩惱內容的細節。

　　第三個特征引發的議題是SOA的服務組合彈性與松散耦合（Loosely Couple）的特性。SOA內的應用模塊若要能輕松改變組合方式，或者改變運行位置，就要藉助SOA的兩個技術特性：松散耦合，以及UDDI(Universal Description, Discovery, and Integration)機制。因為松散耦合，所以某一模塊抽離或添加系統，并不影響其他模塊；因為有UDDI機制，所以新應用模塊添加時，只需跟UDDI服務器登記新服務的界面與所在地點，即可被其他應用模塊搜尋到，并且開始交互。因為有UDDI，所以當某項應用模塊遷離位置，原有使用此應用模塊的其他模塊，可以透過UDDI查找服務的新位置，然后用新位置連結即可。這種特性滿足「經常需要把服務節點拆解再重組」的BPM服務導向經營模式。

　　第四個特征談到的是可管理的SOA Web Services。這是系統管理與軟件管理的議題，雖然當前沒有統一的標準來規范管理軟件與被管理模塊的行為，但當前稍具知名度的SOA環境（特別是Application Server）多半會提供系統管理工具給系統管理員使用，協助管理SOA架構下所有列管模塊的安裝、移除、啟動、停用，以及應用模塊的狀態監控與安全機制。

　　第五個特征，談的是SOA技術架構是模塊化又可彈性串接的特性，在原有SOA環境添加新的技術模塊，即可漸進式提升BPM技術的成熟度。我們從ZapThink整理的SOA藍圖中，可以得知達到不同SOA成熟階段所需具備的SOA技術。舉例來說，假設SOA有階段實施的計劃，那中間過程可以從「點對點集成」開始，進步到「提供松散耦合的服務」，再來是「穩定而可搜尋發現的服務」，接著「提供可組裝與再利用的服務」，進而達到最終目標——「全公司的SOA」。當然，也可從藍圖中得知，不同SOA階段所能獲得的投資回報(ROI)，剛開始只能是「降低應用程序的維護成本，達成點對點的集成」，接著是「透過服務再利用提升效率」，再來是「提升管理能見度與控制力」，最后才是「改善組織的敏捷度」。

　　結語

　　其實，即使是資深的BPM/SOA規劃者，想要跟決策主管解釋清楚SOA的博大精深以及其效用，都是很大的挑戰。主要原因在于其中大大小小的技術條目，以及其相當復雜的關聯。雖然大家都知道，畫出一張易懂的圖解，勝過千言萬語，然而好圖難求，幸好今年(2005)十月ZapThink公司推出一張令人深刻的SOA藍圖海報。這張嘔心瀝血之作，讓人能從各個構面、由入門到高級，逐步探索SOA的世界，而且過目難忘，卻又能夠不失BPM/SOA技術的深度與完整度，實在非常難得，在此推薦這張海報作為延伸閱讀，也當作本文的尾聲。

　　附注

　　1. T.H. Davenport and J.E. Short, "The New Industrial Engineering: Information Technology and Business Process Redesign,", Sloan Management Review, pp. 11-2, Summer 1990. 

　　2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990. 

　　3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993. 

　　4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997. 

　　5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003. 

　　6. 參閱 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005. 

　　7. Web Services Orchestration，簡單說法：使用流程技術來描述并控制Web Services的調用順序，使多個?eb Services依序發生，運行事先安排的工作順序。 

　　8. Web Services Choreography，簡單說法：在跨流程的情境中，以Web Services技術，描述流程個體之間的消息傳遞關系(多半是網狀結構)，以及流程狀態的控制與查詢方式。 

　　9. 參閱本文「天生一對的BPM與SOA」小節 

　　10. BPDM的目的在于提供可通用于多種流程塑模方法的中介模型(meta-model)，以便不同塑模方法生成的流程定義可以互相轉譯。如UML、BPMN，或者其他廠商的專屬表示法，能夠對照到此中介模型，然后互相轉譯；或者讓流程定義轉譯成底層的可運行格式，如BPEL原始碼，乃至于J2EE或 .NET的運行碼。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: http://www.zapthink.com/report.html?id=ZTS-GI103