导入跨组织商业程序管理的问题与解决方法

《导入跨组织商业程序管理的问题与解决方法》由会员分享，可在线阅读，更多相关《导入跨组织商业程序管理的问题与解决方法（15页珍藏版）》请在装配图网上搜索。

1、導入跨組織商業程序管理的問題與解決方法Developing Cross-Organization Business Process Management System: Issues and solution 戚玉樑私立中原大學資訊管理系副教授maxchimail.mis.cycu.edu.tw 李佳曄 私立中原大學資訊管理研究所b88881177何定為工業技術研究院資訊與通訊所摘要商業程序管理(BPM, Business Process Management)是一個匯集企業管理、程序再造、與資訊技術等領域的綜合概念，而程序則是強調爲達到特定商業目的時，編組數個活動並且依序去完成。本研究以服務

2、導向為架構基礎，探討進行跨組織的程序管理時，企業應如何因應複雜的協同作業，特別是導入BPM時須考量的因素與作為，因此提出商業程序管理開發程序作為參考依據。本程序包括三項層面：1).程序再造，由問題的釐清、現有作業的改進、到程序的服務化，以期能將個別程序予以標準化，提升服務的再利用；2).程序塑模，強調程序表達標準化的必要性，因此由個別活動在程序中的輸出/入、編組及描述語言等的使用，皆須在共通的協定及規範下進行；3).程序執行，探討邏輯協定層與訊息傳遞層的分工及可行的方法工具。本研究最後以典型的協同補貨問題(Collaborative replenishment)為例，依照我們提出的開發程序進行

3、建置與說明。由實證經驗顯示，運用本研究的開發程序，確可有系統的指導開發者完成跨組織的商務協同，亦可作為企業開發BPM的參考依據。關鍵字：商業程序管理；網路服務；程序組合壹、緒論企業在資訊科技的實務應用上，已由早期單純的資料處理，逐漸走向具有系統整合概念的應用，例如管理資訊及企業資源規劃等系統，這種稱為程序驅動(Process driven)的資訊應用模式，實際上是以管理工作程序(Workflow)為核心，達到商務協同的目標(Huang and Chung, 2003)。由於企業須朝向國際化發展的趨勢已成型，無論是擴展為跨國的集團組織、或納入於其他組織成為供應鏈的一環，個別企業均須要與其他企業在

4、作業上謀求更緊密的合作，因此資訊技術也擔負更關鍵的角色。為解決複雜的整合問題，各種以跨組織為目的之標準、協定及規範因應而生，其目即為創造一致的溝通環境，以利資訊整合，例如產業的資料交換標準中的RosettaNet及CIDX等。近年來，企業為因應網際網路的蓬勃發展，紛紛導入以資訊技術為核心的商業程序管理(BPM, Business Process Management)，藉以提升產業競爭力及促使企業再造。然而，BPM的成功要素並不僅限於相關軟體工具的應用，相較於企業內部的程序管理，企業在跨組織的BPM中只扮演部分角色，因此在管理的視野上，應由傳統的企業高度提升到產業高度(Industry-wid

5、e)，分析的角度也須由如何融入產業社群為首要課題逕行改造。網路服務是由網際網路標準組織(W3C, World Wide Web Consortium)所發展的應用系統整合規範，它強調藉由XML訊息的封裝及傳遞，達成異質環境所需克服的互通性問題，例如系統之間的操控與識別，由於這項技術在系統開發上具有化繁為簡及求同存異的特性，因此已廣泛應用於企業的資訊系統整合(Curbera et al., 2002)。近年來，各項以網路服務規範為基礎的開發工具也逐漸完備，例如程式開發語言有Java及.Net等、整合性開發環境的工具有IBM WebShpere及BEA Web Logic等。網路服務創造了應用系統

6、(服務)易於整合的環境，所有的服務並未侷限於企業內，它們皆可透過網路由不同的企業提供，此種開放且支援分散式的運作架構，稱為服務導向架構(SOA, service oriented architecture)。簡言之，服務導向架構提供跨企業環境(Industry-wide)的整合基礎，也促使企業更容易完成與其他企業的商務協同(Zhao and Cheng, 2005)。服務導向架構在應用系統的需求、提供及管理上，都以XML訊息傳遞方式，改善應用系統在跨平台操控上(interoperable)的一些難題，然而對於結合其他應用系統成為具有程序性或程序能力的應用時，仍需要其他規範或技術的支持(Zhao

7、 and Cheng, 2005)。本研究即為探討在服務導向架構下，企業如何執行與其他企業的商務協同。我們認為企業之間的商務協同，由下至上可概分為程序再造、程序管理及程序執行等三個層次。本研究的執行即為應用系統的網路服務化，以及服務導向架構；管理是指商務協同所需的規範標準及其執行的語言格式；最後，程序再造是指為達成某項特定商業目的所組織的程序、規則或決策判斷。有別於企業內的商務協同，通常處於已知及可掌握的情境下進行，企業之間的商務協同則普遍涉及外來成員，它們在程序再造、管理及執行等的內容與銜接上成為問題，因此充斥許多不確定性的因素(Medjahed et al., 2003)。本研究嚐試發展跨

8、企業的商務協同導入程序，提出商業程序管理開發指導(BPM Development Guide)，由抽象的概念對應至具體的實施步驟，以期企業能依照系統化的步驟，發展跨企業的商務協同。本研究最後以協同補貨(Collaborative replenishment)問題為例，依照商業程序管理開發指導所律定的平台、語法及邏輯等來解決。由實證經驗顯示，運用本研究的理開發指導，確可系統化的完成跨企業的商務協同。在下面的章節安排中，第二節整理商業程序管理的定義與背景資料分析；第三節探討商業程序管理開發指導，調查目前對應的方法或工具，並發展具有次序階層的技術堆疊架構；第四節，我們依據所提出的商業程序管理開發指導

9、，以流通業的規劃、預測及補貨程序為例，驗證BPM Guiding Stack如何指導商業程序管理的推出；最後，我們討論商業程序管理的技術堆疊的效益及後續研究建議。貳、 背景介紹及文獻探討商業程序管理是關於如何協助企業組織具體提升效能與降低成本的學理、方法或工具。商業程序管理的定義、範圍及相關的研究，事實上也包羅萬象。首先，就商業程序管理之定義而言，人類的商業行為從以物易物到工業社會的大量生產、再演進到國際貿易的分工合作、及資訊時代所創造的地球村，雖然各階段所強調的程序對象或內涵有些不同，例如生產的數量、成本、品質或時間等，但其意義仍在於追求企業組織的自我成長、創新及再造(Lindasy, et

10、. al., 2003; van Rensbury, 1998)。其次，就商業程序管理之範圍而言，企業的資源管理、需求預測、與程序控制等，舉凡與提升競爭力有關的模型架構、規範及技術，均可視為商業程序管理的範圍(McAdam, et al., 2005 ; Smith, 2003)。最後，在商業程序管理的學術研究上也有許多不同的構面，例如：以技術的觀點探討如程序整合、自動化及代理人等；以企業資源的觀點探討如組織結構及企業文化等的精進等；以作業的觀點探討如商業模型、規範協定等(Delen et al., 2005)。因此，商業程序管理代表企業或組織在追求卓越時，所有在行為及工作上的概念名詞。在跨平

11、台的資訊應用系統中，資訊共用及資源共享是整合的目標，而操控性(interoperable)的優劣，例如通訊協定、作業方式、甚至於開發語言等，則是檢驗系統整合的具體指標，過去常用於應用系統整合的中介軟體，例如物件管理組織的CORBA規範及微軟公司的分散式元/物件模型(DCOM)等，都是重要的分散式運算架構(Vinoski, 1997)。相較僅侷限在微軟作業環境的DCOM架構，CORBA的開發及應用範圍均較大，因此操控性也相對較強。由於XML的快速興起，傳統以中介軟體為主的系統整合，也逐步以更具彈性的網路服務技術取代，Kou et al. (2000)即指出網路服務架構可溯源至XML規範，它使用A

12、SCII code而非二元碼的文字格式，因此可應用在各領域中做為基礎的資料交換方式。根據網際網路標準組織(W3C)對網路服務的定義：網路服務是指一個應用程式可經由XML來描述、查詢以及利用URI來辨識，此應用程式的介面與鏈結方式均已被完整定義，且支援其他的應用程式，並能藉XML型式的訊息經合乎網際網路的協定來直接驅動。為支援網路服務的作業環境，W3C也推展服務導向架構，將網路上的角色可劃分為服務的需求者、提供者和仲介者等三類，並以三項規範來界定各角色間的互動方式及作業依據，它們分別是：1. SOAP規範(Simple Object Access Protocol)：其用途是將XML訊息的傳遞機

13、制格式化，以完成服務之間的查詢、發佈、和執行。目前SOAP並未定義其專屬的通訊協定，而是使用開放原始碼組織(OSI, Open Source Initiative)應用層現有的協定，例如HTTP。2. WSDL規範(Web Services Description Language)：其用途是定義網路服務有關資訊的描述語言，諸如表達服務之間的協議、關聯及個別服務的執行細節，目前WSDL規範僅包含個別服務的執行細節。3. UDDI規範(Universal Description, Discovery, and Integration Protocol)：提供建置服務註冊中心及提供者或需求者的操作

14、依據，亦即提供服務導向架構下的仲介機制，目前UDDI規範並未納入W3C管轄，而是由UDDI組織(http:/www.uddi.org)訂定。近年來，網路服務已成為業界共通的系統開發方式，各種支援工具也趨於完善，因此對於發展跨組織的應用系統而言，應是最具效益且方便可行的方式。由於個別程序的開發以網路服務化，因此管理這些服務的程序也需因應跨組織環境而朝向標準化發展。為符合網路服務運作的基本特性，現階段支援商業程序的規範也是利用XML的形式來描述程序該怎麼走、網路服務之間又是如何互動等細節，近年來發展的程序語言有十餘種，本研究針對較具規模及潛力的四個組織整理如下：1. BPMI (Business

15、Process Management Initiative)：BPMI是針對企業程序管理議題的非營利性組織，主要成員遍及企管顧問及資訊業界如IBM, SAP, PeopleSoft, Adobe, BEA等。BPMI在2005年併入OMG組織(Object Management Group)，目前致力於工作程序模型樣式的制定，透過發展程序在設計、建置、執行、維護及最適化等不同階段的標準，提倡企業程序管理的應用，讓企業能夠執行標準化的程序管理，並且協助軟體廠商推展BPM的相關產品及企業應用的相關技術，BPMI制定了幾個與商業程序有關的規範，例如BPMN, BPML, BPQL等(Smith, 2

16、003)。2. ebXML (Electronic Business using XML)：ebXML是由OASIS及UN/CEFACT共同成立的非營利組織，其目的在建立一個以XML為基礎的開放性架構，提供企業間電子商務的通用格式，以利電子商務在透明、安全、與一致性的環境下交換商業資訊。ebXML提供一系列的技術規範，包括技術架構、商業程序、註冊資訊模型、註冊服務、需求、合作協定細節與契約、及訊息服務等，目前上述規範除商業程序由UN/CEFACT負責主導外，其餘規範則是由OASIS的各技術委員會負責研發。ebXML的商業程序規範是BPSS(Business Process Specificat

17、ion Schema)。3. WfMC (Workflow Management Coalition)：WfMC是專為工作程序議題所設立的非營利性組織，組織成員包含了程序解決方案的供應廠商、使用者、分析師、學術單位，它是目前軟體界重要的工作程序標準的制定組織之一，該組織主要的任務在於：增加企業應用工作程序技術所產生的價值、降低企業應用工作程序產品的風險、及增加企業對工作程序的認知以擴大工作程序產品的市場。WfMC與商業程序有關的規範是XPDL(XML Process Definition Language)。4. OASIS (Organization for the Advancement

18、of Structured Information Standards) 是專為製作網際網路標準的非營利性組織，目前OASIS所出版的規範均以XML在相關領域的應用為主，其中與商業程序有關的規範是BPEL4WS (Business Process Management for Web Services)，這個規範是由IBM, Microsoft及BEA共同提出，它其實融合了IBM WSFL及MS XLANG二項知名的程序語言，目前極具有競爭優勢的程序描述語言之一。如圖一所示，程序描述語言的發展過程中，通常是由非營利組織或協會來研擬規範，成員包含學術、研究機構、軟體商等，經嚴謹的開發過程後以規範

19、、標準或語言等不同形式公佈，軟體商或自由軟體組織再分別開發對應的編輯器或執行程序平台，使用者則在共通的環境中編組程序。商業程序管理在利用網路服務時，需透過程序描述語言及其塑模(Modeling)，將程序活動編組為符合程序描述語言的文件，再交由程序引擎完成商業程序的執行。圖1：程序標準的開發與支援環境的關係參、 發展商業程序管理開發指導為協助企業在推動商業程序管理的相關作業，本研究提出包含程序再造、管理及執行等三項構面的開發指導架構，並探討每項構面應納入考量的項目如圖1所示。儘管商業程序管理有許多基於不同觀點的詮釋及定義，例如以系統執行或模型等，商業程序管理應是技術與管理藝術並重的領域，因此企業

20、在導入商業程序管理的方法工具時，也應重視其他支援的環境條件。商業程序管理開發指導企圖提供上層的抽象原則並對應可行的步驟，使得在跨組織的異質環境中，企業可系統化的完成商業程序管理。在圖1中，由左至右分別表示：(1). 真實世界的事件，我們須由問題的釐清到概念的項目化，此為程序再造階段。(2). 商業程序，是指將實體問題予以虛擬化的過程，包括確認個別服務的輸出入、遵循的程序標準或描述語言、及組合服務成為商業程序，此為程序管理階段。(3). 結果執行，將商業程序利用服務導向架構的環境，並以服務程序的執行引擎執行，此為程序執行階段。 圖2：商業程序管理開發指導的三階段概念一、程序再造(Process

21、re-engineering)程序再造階段須處理關於作業程序的整理、分析與改善，解決現有企業程序中不合時宜的設計，並逐步導引至具有效益的目標。本階段的內涵雖然類似一般軟體開發的需求分析，但差異在商業程序是由多個程序所組合，個別程序可能納入其他的程序，因此任何程序的變動，將牽動其他程序的結果。Van Rensbury (1998)認為發展成功的商業程序管理，組織內的成員須體認變動及其影響是全面性的，他曾建議三項方法：以相同的商業語言溝通、延伸企業相同的觀點、及固定且一致的變動程序。簡言之，本階段的內涵期望達到嚴謹和專業的企業程序再造。以下分別說明此階段的主要工作項目：1. 商業程序問題分析：企業

22、現役的管理系統多是專屬目的之套裝系統，強調以垂直及功能性方式，解決特定領域的應用，例如ERP著重企業內的生產、庫存、財務等相關程序。商業程序的問題類型，通常是水平橫向及跨組織的功能串聯，例如物流問題等。這種程序驅動的方式應融合價值鏈、管理與企業文化等的改造，才可創造程序外部化。2. 商業程序問題的標準化：企業在解決內部的程序問題時，通常須遷就本身的人員組織、營運模式、企業文化等影響因素，但跨越系統或組織的商業程序，因為所植基的影響因素各異，故程序問題須跳脫企業內部的思考範疇，將問題予以抽象化，並使用通用的案例、模型或標準，例如結合協同規劃、預測及補貨方法(CPFR)於跨組織的程序問題、使用統一

23、的資料交換標準如RoseetaNet，以確保在相同的基礎上溝通資料等。3. 程序再造修訂：程序再造常隨時空環境的改變而不同，因此須經常予以修正，而BPM系統也須建立與這些更新的程序，產生綿密的互動關係，以維持與現況的一致性。二. 程序塑模程序塑模式指如何將程序中的個別活動，依照前述的分析予以開發及編組，並以程序描述語言表達程序模型。兩項主要工作：編組程序模型及異常處理(Exception Handler)，說明如下：1. 編組程序模型：有別於企業內部的程序管理，跨組織的商業程序通常面臨不同開發環境及程序作業方式，因此需採用共通的程序描述語言，圖1中的BPEL、BPML、XPDL等均是現役的程序

24、描述語言。在編組網路服務為商業程序時，每項服務的細項作業可視為獨立的活動，由於各活動的輸出入資料具有相依性，例如形式上的訊息型態及邏輯上的資料意義等，因此在程序編組前應先取得各成員對程序邏輯的共識。圖3左側是網路服務的WSDL文件，其中input message代表觸發此活動所需的訊息，編組程序時需對應至圖3右側活動的輸入(例如註標)；output message代表完成此活動所產生的訊息，程序編組時需對應至輸出註標()。圖3 服務描述文件(WSDL)與程序編組的關係各別活動而言，他涉及的邏輯只限定在相關的輸出入資料，並將由服務描述文件提供，因此程序各成員參與一種抽象程序(abstract p

25、rocess)的編輯；另一方面，為使程序能依照某種商業行為執行，例如在訂貨程序中，若Clinet訂貨數量大於某數量時則流向A活動，反之則流向B活動，由於各活動無法訂定自身以外的邏輯，因此程序管理者則是以實作程序(executable process)的角度，編輯活動的次序及一些加諸於活動之間的條件判斷，由於時作程序涉及內部的決策方式，因此不需要程序各成員的參與。圖4說明網路服務透過WSDL文件提供程序編組所需的活動，而各活動僅參與程序的抽象程序，實作程序則是有效的將活動組合成為主程序定義。圖4 程序編組的主程序與輔助程序2. 異常處理：商業程序是一種長時序交易(LLT, Long-lived

26、Transaction)的程序活動，造成商業程序發生異常(Exception)的情況很多且無法避免的部分可掌握的異常或錯誤，應於程序設計階段擬妥因應的處理步驟，對於其他不可具體預期的異常，則應藉歸納異常的類型，尋求標準化的處理方式。常見的異常類型如軟硬體故障、人為疏失、逾期、資源調度失敗、外部干擾等。異常處理的因應機制則包括中止、邏輯條件、修正及補償等，但每項程序活動的異常類型及異常處理機制尚須視情境彈性調配。三. 程序執行在執行組織或企業之間的協同商務時，遵循統一的標準規範可確保溝通環境的一致性，也是達成互相操控(interoperable)的重要基礎。圖5說明商業程序執行時所需要的支援環境

27、，圖中最上層的三角形代表可跨組織的企業程序管理，其餘由下而上代表所須技術的堆疊架構，說明如下：1. 利用網路服務技術開發程序的個別程序，各程序須以網路服務描述語言(WSDL)提供服務執行細節，並登錄至服務註冊中心。2. 架構具服務導向架構的環境，以協助SOAP訊息時的解譯及執行。由於SOAP本身並沒有實際的傳輸協定，因此傳遞時通常須利用HTTP來封裝方式，稱為SOAP over HTTP，目前大部份的軟體開發工具都已支援，例如.NET及Java平台。3. 程序通常藉圖形化的整合開發工具(IDE)，提供程序概念的視覺化編輯，所產生的程序模型再轉置為指定的BPM的描述語言格式，並提供程序引擎執行或

28、登錄為另一網路服務。4. BPM程序引擎具有執行及監督程序的能力，一旦取得BPM的描述檔後，該引擎即擁有程序的控制權。以技術層面而言，程序引擎須架構於SOA環境之上，因此也是以SOAP over HTTP方式運作。圖5：BPM技術的堆疊架構肆、 範例實作：協同補貨企業在變動快速的環境下，面臨了許多的新問題，然而也增加了許多需求。例如人工作業錯誤、缺乏程序工具與管方法、程序資產缺乏重用能力、跨組織程序的需求。人工作業常會發生非蓄意性的錯誤，如資金調度錯誤、客製產品報價錯誤，在這些錯誤之中，有形無形之中都增加了企業的成本，本範例藉由實做協同補貨程序，以協助人工作業，降低錯誤發生。正常的商業程序必然

29、包含程序參與者與程序邏輯，諸如對話式商業程序、條件式商業程序、長時序商業程序與例外處理式商業程序等商業程序之型態，其商業程序可以擁有一至多個型態並存，本範例單就對話式商業程序之規劃、編組、塑模等進行以協同補貨為例做示範。對話式商業程序的參與者必定為兩者以上成員參加，商業程序的規劃階段必須建立協同的關係，明確指出商業程序參與者所扮演的角色，以及建立商業程序共同的目標。本節的假設例子明確指出共有兩個參與者：Customer與Supplier，Customer為需求方的角色定位；Supplier為供應方的角色定位，而共同的營運目標是多次發起的商業程序之情況下，可以隨時掌握不同商業程序的程序狀況，諸如

30、某批號的訂單是否完成付款之程序等等。商業程序的參與者完成角色定位後，相對其可以做的事情早已經隱式的歸納好了，本例子的Customer為需求方，諸如詢問價格、下訂單、付款等都是Customer所應具備的能力，而Supplier為供應方，回報詢價、確認收款、出貨也是Supplier應當具有的能力，如果發生Customer具備出貨能力的邏輯衝突時，就必須重新定義角色的定位，直到角色的定位合乎邏輯。程序參與者所應具備的能力，同時也是Web Services編組時的參考，也就是說Web Services所提供的功能必定包含程序參與者所具備的能力。完成編組作業，繼續進行BPEL塑模的前置作業，主要的內容為

31、商業程序邏輯的規劃，必須定義程序流與資料流等等，本例子的商業程序邏輯如圖6所示：圖6：商業程序邏輯BPEL的塑模作業包含WSDL文件的取得、WSDL文件的Partner Link Type定義以及BPEL的塑模。取得WSDL文件就是取得該服務的使用權，服務欲加入BPEL即是先從WSDL著手，而為WSDL文件定義Partner Link Type其目的為的是描述Process與Service之間的關係，BPEL與WSDL即透過相同Partner Link Type名字來連結完成，以及BPEL透過不同的Partner Link的名字來區別不同的服務夥伴，其關係可由圖7說明之。圖7： Partner

32、 Link關係圖BPEL的塑模就是將商業程序邏輯以BPEL規範既有的標籤或語法將其定義成BPEL文件，本例子的BPEL文件以ActiveBPEL的ActiveBPEL Designer製作而成，其片段的BPEL文件如圖8所示：圖8：BPEL文件伍、 討論商業程序管理致力於企業組織的模組化、商業交易的程序化及資訊技術的整合，並逐漸形成管理及資訊技術兩大構面的匯流：前者如企業程序再造(BPR, Business Process Reengineering)、企業資源規劃(ERP, Enterprise Resource Planning)、供應鏈管理(SCM, Supply Chain Manag

33、ement)等；後者如資訊技術的應用，例如網路、規範協定及系統整合等。著眼於當前多元競爭環境，企業除需持續發展本身核心技術能力外，亦須加強降低有形或無形的成本。簡言之，國際化的競爭促使企業必須在為利的時代下錙銖必較，因此導入商業程序管理的概念，可發揮管理及資訊兩大構面的綜效。商業程序管理的定義及範圍包羅萬象，舉凡能具體提升企業效能與降低成本的學理、方法或工具，都是符合商業程序管理之目的。以資訊技術的觀點而言 , 商業程序是指完成一項商業目的所做的相關活動，具有整合多個活動的程序概 念，這種稱為程序驅動(Process-driven)的應用模式，實際上是以工作程序為核 心，達到商務協同的目標 (

34、Huang and Chung,2003)。由於網路技術的成熟，商業程序管理的範疇逐漸應用在跨組織的環境，如何將隸屬於不同組織的活動，整合成能共同協同的商業程序，須克服異質環境的整合問題。近年來，以XML為基礎的網路服務技術(Web Services)，強調以鬆散耦合(Loosely Coupled)的作業平台及訊息傳遞的溝通機制，有效解決過去異質環境的整合問題。然而，跨組織的商業程序也意謂著程序是處於長時序的交易環境(LLT, Long-Lived Transaction)，如何處理程序的異常(Exception)或錯誤回復(Fault Recovery), 是提升服務品質的重要指標之。陸、

35、 結論企業在推動商業程序管理時，應考量企業文化、產業特性、及技術支援能力等，找出適合本身的導入方式，才是務實的商業程序管理。由於網路及資訊技術的不斷變革，原來屬於上述實體的商業行為，也逐漸利用資訊技術來模擬，例如資料的標準化及作業程序等。虛擬企業的範圍並不侷限於電子資料處理，它更試圖將事件之間的行為納入，例如程序控管，及企業之間的溝通商議，例如代理人協商或協定等。因此，資訊科技的觀點逐漸成企業在推動商業程序管理的重心。由於商業程序管理的本質仍為一種抽象的概念，引進某個BPM的理論或工具並不意謂達成商業程序管理，我們不認為某個企業的成功範例可以適用於其他企業，甚至於同一企業內的不同領域。柒、參考

36、文獻Curbera, F., Khalaf, R., Mukhi, N., Tai, S., and Weerawarana, S. The next step in Web services, Communications of the ACM , Vol. 46,No.10, 2003, 29-34.Delen, D., Dalal, N. P., and Benjamin, P. C. Integrated modeling: the key to holistic understanding of the enterprise, Communications of the ACM ,V

37、ol. 48, No.4, 2005, pp.107-112.Huang, Y. and Chung, J. A Web services-based framework for business integration solutions, Electronic Commerce Research and Applications ,Vol. 2, No.1, 2003, pp. 15-26.Lindsay, A., Downs, D. and Lunn, K. Business processes-attempts to find a definition, Information and

38、 Software Technology ,Vol.45, No.15, 2003, pp. 1015-1019.McAdam, R., Keogh, W., Galbraith, B. and Laurie, D. Defining and improving technology transfer business and management processes in university innovation centres, Technovation ,Vol. 25, No.12, 2005, pp. 1418-1429.Medjahed, B., Benatallah, B.,

39、Bouguettaya, A., Ngu, A.H.H., and Elmagarmid, A.K. Business-to-business interactions: issues and enabling technologies, The VLDB Journal ,Vol. 12, No.1, 2003, pp. 59-85.Smith, H. Business process management-the third wave: business process modeling language (bpml) and its pi-calculus foundations, In

40、formation and Software Technology ,Vol. 45, No.15, 2003, pp. 1065-1069Vinoski, S. 1997. CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. In Proc. IEEE Communications Magazine, Vol. 14, No. 2, February.Zhao, J. L. and Cheng, H.K. Web services and process management: a union of convenience or a new area of research? Decision Support Systems ,Vol. 40, No.1, 2005, pp. 1-8.