基于事例處理的工程項目工作流管理

1、基于事例處理的工程項目工作流管理 隨社會生產的流程化，工作流起著越來越重要的作用。工作流的概念起源于生產組織和辦公自動化領域，它是針對日常工作中具有固定程序的活動而提出的一個概念。目的是通過將一個具體的工作分解成多個任務、角色，通過一定的規(guī)則和過程，約束這些任務的執(zhí)行和監(jiān)控，以達到提企業(yè)生產經管理水平。 隨著互聯(lián)網(wǎng)技術的發(fā)展及應用，促進電子/a商務應用的極大發(fā)展，使得組織與組織之間、組織內部部門之間的業(yè)務相互處理成為可能，這為工作流的發(fā)展帶來了很大的機遇和挑戰(zhàn)。按照工作流管理聯(lián)盟（ workflow management coalition WfMC) 的定義，工作流是指“計算機應用環(huán)境下業(yè)務

2、過程的部分或全部自動化”，其目的在于“使得在多個參與者之間按照某種預先定義的規(guī)則傳遞文檔、信息或任務的過程自動進行，從而實現(xiàn)某個預期的業(yè)務目標或是促使此目標的實現(xiàn)”。 1、工作流管理系統(tǒng)為了實施對業(yè)務過程的工作流管理，需要相應軟件系統(tǒng)的支撐，這種軟件系統(tǒng)可稱為工作流管理系統(tǒng)。工作流管理系統(tǒng)的定義是：“工作流管理系統(tǒng)是一個軟件系統(tǒng)，它完成工作流的定義和管理，并按照在計算機中預先定義好的工作流邏輯推進工作流實例的執(zhí)行?！币话愣裕ぷ髁鞴芾硐到y(tǒng)應包含如圖1所示的三個組成部分： 定義建模；運行控制；運行交互。傳統(tǒng)工作流管理系統(tǒng)的運作原理如下：相應的工作流過程定義對每個新的事例予以實例化，即為每個事例

3、創(chuàng)建一個新的工作流實例?；谙鄳墓ぷ髁鬟^程定義，工作流引擎計算對于該事例應激活哪些活動。 針對每個被激活的活動，將生成一個工作項并放入每個具有相應角色的用戶的“工作夾”。 用戶從其工作夾中選擇工作項，并開始執(zhí)行相應的活動等。盡管一個工作項可以出現(xiàn)在多個用戶的工作夾中，但只有一個用戶執(zhí)行相應的活動。 當一個工作項被選中后，工作流管理系統(tǒng)將啟動相關的應用程序并監(jiān)控相應活動的執(zhí)行結果。需要指出，用戶只能看到在其工作夾中的工作項，并且當選擇一個工作項時也只能獲知與執(zhí)行相應活動有關的信息24 。2、基于事例處理工程項目工作流管理的概念工程項目可以看作是一項任務，有許多過程和活動構成，但與制造業(yè)工業(yè)部門

4、不同的是，工程建設過程具有高度的復雜性，而這種復雜性又可以在總體上分為弱結構化和變動性兩個方面。正如同大約90%的工程建設信息是非結構化的文檔信息，工程建設中絕大多數(shù)處理過程屬于非結構化或弱結構化的工作過程。 對于這些非結構化或弱結構化過程的支持，根本無法采用傳統(tǒng)的工作流管理技術。同時，工程建設領域也存在一些諸如設計變更、工程索賠以及招標采購等具備較高結構化程度的管理過程。這些管理過程盡管數(shù)量較少，但具有相當?shù)闹匾?，有研究指?5 %的建設問題和過程有關而和產品沒有太大關系，因此如何實現(xiàn)工程建設過程的管理工作流自動化仍然有著重要的意義。 但必須注意到，由于這些管理工作流具有一定程度的變動性，

5、嚴重依賴于固定的事先過程定義的傳統(tǒng)工作流管理技術，無法對其提供有效的支持。事實上，許多研究人員都指出：由于缺乏靈活性，傳統(tǒng)的工作流管理技術在工程實踐中經常以失敗告終。傳統(tǒng)的工作流管理技術之所以缺乏靈活性，其關鍵原因在于路徑是驅動工作流的唯一機制，即工作是基于預先固定的因果關系從一個工作夾流轉到另一個工作夾。因此，所導致的過程模型或者過于簡單或者過于復雜和非透明。 針對以上原因，近年來一些學者提出了所謂的事例處理系統(tǒng)（casehandling system），倡導一個根本性的思想轉變：工作流的驅動不是通過預先確定的路徑，而是應該通過事例。傳統(tǒng)的工作流管理技術側重于在一個工作流過程中“應該做什么”

6、，而事例處理技術則側重于為了取得業(yè)務目標“可以做什么”。作為一種新的工作流管理方法，事例處理技術為支持靈活的、知識密集的業(yè)務過程提供了新的可能性。事實上，事例處理原則的應用已經在荷蘭一家名為海杰曼斯的大型建公司的一些項目中獲得了巨大的成功。簡單而言，事例是工作流過程的一個實例，是工作流參與人員所需處理的對象。 在工程建設領域，事例可以是一個具體的設計變更過程、一個具體的工程索賠過程以及一個具體的招標采購過程等。如果將事例看作是通過執(zhí)行工作流過程所制造的產品（建設管理過程的產品是信息），則真正驅動工作流過程的是產品的特征。 通過關注產品的特征，可以將傳統(tǒng)的面向“推”的路徑（從一個工作夾到另一個工

7、作夾） 轉變?yōu)槊嫦颉袄钡臋C制（以關于一個事例的數(shù)據(jù)對象為中心） .為了進一步說明基于事例處理的工作流管理方法，通過統(tǒng)一建模語言（UML） 提出其相應的對象模型（圖2）。3、基于事例處理的工程項目工作流管理的過程定義對于基于事例處理的工程項目工作流管理而言，同樣需要進行過程定義。 傳統(tǒng)的建設過程被認為是彼此分裂，在沒有應用信息系統(tǒng)時，信息呈孤立狀態(tài)，形成了“信息孤島”；在信息系統(tǒng)應用后形成了一定的工作流；但是還需要應用過程管理思想對信息系統(tǒng)的工作流進行集成和優(yōu)化，即在利用流程再造（BPR）工具進行業(yè)務過程重組和優(yōu)化的基礎上描述工程項目工作流的過程邏輯。過程定義所產生的過程模型是整個工作流管理系

8、統(tǒng)的基礎。許多工作流管理系統(tǒng)的開發(fā)平臺均提供可視化的過程建模工具，使得用戶能夠以直觀的方式對實際的業(yè)務過程進行建模，而且所建立的過程模型可以直接得到系統(tǒng)的支持。過程建模的方法有活動網(wǎng)絡圖、有向圖、Integration definition method（ IDEF3） 以及Petri網(wǎng)等等，其中的Petri網(wǎng)過程建模方法近年來最為學術界所重視5 ，6 .以下采用簡化Petri 網(wǎng)模型對任務管理過程予以建模。 在一般性的任務管理過程中，團隊領導首先要求團隊的某個成員完成一個任務。該團隊成員基于自身能力和各種約束條件檢查任務要求，然后發(fā)送一個答復給團隊領導。如果該團隊成員認為無法完成該任務，則團

9、隊領導需要物色其他合適的團隊成員。如果該團隊成員確認有能力完成該任務，則團隊領導對任務進行詳細描述，并將其發(fā)送給該團隊成員。當該團隊成員對任務的詳細描述不理解時，他可以提出詢問，直到該任務被理解并被實施。對于團隊成員所提交的任務結果，團隊領導將其與原來的任務狀況說明相比較。如果認可，則提交工作成果。否則，團隊領導將任務重新退回給該團隊成員（圖3）。 4、基于事例處理的工作流管理系統(tǒng)的體系結構通過上節(jié)的分析，圖4給出了基于事例處理的工作流管理系統(tǒng)的體系結構，該體系結構與工作流管理聯(lián)盟所提出的參考模型基本一致7.系統(tǒng)的邏輯設計包括過程定義、用戶的角色分配、數(shù)據(jù)處理設計、表單定義、事例的授權與分配等

10、方面。 工作流執(zhí)行服務中的工作流引擎是整個系統(tǒng)的核心，主要負責工作流過程實例的執(zhí)行、事例活動的狀態(tài)控制、用戶事例列表的維護以及對外部資源的訪問等工作。管理監(jiān)控工具對運行過程中過程實例的狀態(tài)進行監(jiān)控與管理。工作流引擎通過代理，可以訪問過程數(shù)據(jù)、用戶信息和文檔信息等數(shù)據(jù)庫資源。客戶端應用程序為用戶提供一種手段，以處理過程實例運行過程中需要人工干預的任務。而被調用的應用程序是指工作流執(zhí)行服務在過程實例的運行過程中所調用并對應用數(shù)據(jù)進行處理的外部應用程序（比如文檔管理模塊） .圖中的幾個WAPI （workflow applicationpicture interface） 依賴于確定的開發(fā)平臺。根據(jù)

11、該體系結構，可以通過Lotus Domino/ Notes 中的Flow2 Mark 工作流開發(fā)平臺來予以實施。5、案例圖5 給出了基于事例處理的工程項目工作流管理系統(tǒng)的界面。 在工作區(qū)域的上部窗口是當前正在執(zhí)行或查看的流程，其中可能包含子流程。下部左邊的窗口相應顯示當前流程中的活動和子流程。下部右邊的窗口則是與當前流程所相關的表單、文檔等信息。從圖中可以看出，系統(tǒng)當前流程為“某設計方案的變更”，其中包含一個“登記某設計方案的變更要求”的子流程和“修改某設計方案”、“審核新的設計方案”、“歸檔并分發(fā)”三項活動。對于該界面，需要說明的是： 活動和子流程的狀態(tài)可以是待辦、在辦、已辦、略過以及重做等

12、等，比如張三（假設為設計方人員） 對于審核新的設計方案不具有執(zhí)行角色，因而對該活動可以略過； 所打開的表單應標明哪些是強制數(shù)據(jù)、哪些是限制數(shù)據(jù)，比如設計方案審核表單中的“同意與否”應為必須填寫的強制數(shù)據(jù)。當然，殼- 核結構模型也有它的不足之處，主要體現(xiàn)在以下2 個方面：（1） 殼- 核結構的定義還不是十分精確，因此需要開發(fā)人員精心地去劃分系統(tǒng)層次，并在開發(fā)過程中摸索總結經驗。這會增加些額外的工作，尤其是剛開始的時候。（2） 殼- 核結構模型的目的是為那些與外界聯(lián)系復雜的信息系統(tǒng)提供簡化其系統(tǒng)結構的途徑，因而對于那些相對孤立、簡單的系統(tǒng)，運用殼- 核結構就有點得不償失了。無論如何，從系統(tǒng)設計開始

13、就考慮與其他系統(tǒng)的協(xié)作，而不僅僅是功能的可擴展，可以體現(xiàn)真正意上的開放系統(tǒng)。 平臺是否一致并不重要，信息技術的發(fā)展可提供足夠技術去實現(xiàn)異構系統(tǒng)的協(xié)作?？梢韵胂笞裱撤N原則來實現(xiàn)系統(tǒng)間協(xié)作，以致構成極富彈性的信息系統(tǒng)體系，應比遵循某種技術標準來實現(xiàn)系統(tǒng)的集成要靈活很多。STRONG參考文獻： 1 Stephen R Schach. Object2oriented and classical software engineer ingM.5th ed.New York ：CITIC Publishing House/ McGrawHill ，2002.2 戴汝為。系統(tǒng)科學與復雜性科學A .系統(tǒng)科學

14、與工程研究C.上海：上?？平逃霭嫔?，2000.1-11.DAI Ru2wei.Systems science and complexity scienceA.Systems Science and Engineering ： Theories and Applications C . Shanghai ： Shanghai Scientific and Technological Education Publishing House ，2000. 1 - 11. 3 錢學森，于境元，戴汝為。一個科學新領域開放的復雜巨系統(tǒng)及其方法論A.系統(tǒng)科學與工程研究 C.上海：上?？萍冀逃霭嫔?，2000. 632 - 643.QIAN Xue2sen ，YU Jing2yuan ，DAI Ru2wei. A new domain of science open complex giant systems and its methodology A . Systems Science and Engineering ： Theories and Applications C .Shanghai ： Shanghai Scientific and Technological Education Publ