所謂ERP系統工作流（workflow）就是一系列相互銜接、自動進行的業務活動或任務，是經營過程的全部或部分自動化。當前工作流的研究與應用在我國主要側重于工作流的實現技術。在動態變化的國際市場競爭環境中缺乏隨機響應能力，因此工作流的智能性和動態性還有待提高。
因此，作者在對工作流過程元模型擴展的基礎上，提出了一個智能動態工作流模型（intelligent and dynamic workflow model，IDWFM）。該模型在工作流中引入可擴展規則控制流程的智能動態流轉，并且提出一個獨立于工作流系統的流程規則協調器（flow-coordinator，FC）完成規則的解析。該協調器可以識別用戶輸入的信息，通過對輸入信息以及規則的解析實現流程的智能選擇以及動態運行。在FC的支持下，工作流管理系統的柔性和通用性也獲得了提高。最后，通過一個具體的實例說明了基于IDWFM開發的工作流管理系統的動態性和智能性。
1 工作流過程元模型的擴展
工作流管理聯盟（workflow management coalition）定義了一個工作流過程元模型，該模型通過活動（activity）、轉移條件（transition conditions）、角色（role）、工作流相關數據（workflow relevant data）、被調應用（infoked application）5類元素描述工作流的組成及邏輯關系。該模型適于描述具有標準、穩定的流程輸入和輸出業務，以利于業務過程能夠一致、準確、高效、可靠地執行。當前工作流專注于業務流程的表示，工作流元模型不支持流程動態生成以及智能流轉的描述。為此，對原有的工作流過程元模型進行擴展，并做相應的變化，使得工作流中動態因素在元模型中更好地描述。圖1為擴展后的工作流過程元模型。
圖1 擴展的工作流過程元模型
在圖1中，白色方框是工作流管理聯盟的過程定義元模型，陰影部分為新引入的元素，分別是可擴展規則（extent rule）和規則引擎（rule engine）。可擴展規則主要包括路由規則、活動屬性更改規則、自定義規則3種約束規則。這些規則是指流程運行過程中動態變化以及智能更改所必須遵守的約束條件。路由規則負責控制流程的走向；活動屬性更改規則主要負責控制流程運行過程中工作流活動屬性變化；自定義規則是指工作流運行中活動參與者自己定義的規則，通過它工作流系統可以實現全部或部分環節的自動運行、智能流轉。活動參與者定義的規則包括上級定義的規則和用戶自已定義的規則，前者定義的規則優先級高于后者。通過引入可擴展規則后所得到的新模型可以更好地描述工作流中動態變化的各個因素，實現工作流的動態性以及智能性。
規則引擎主要負責對擴展規則以及轉移條件進行解釋分析，并把分析判斷的結果傳遞給工作流引擎。規則引擎根據需要調用流程規則并且對規則進行分析判斷，根據分析的結果實現流程的動態變化和智能流轉。
在工作流管理聯盟定義的工作流過程元模型的基礎上添加了可擴展規則和規則引擎后，該模型可更好地描述流程中的各動態因素，為建立業務流程提供充分的擴展性。基于添加了可擴展規則和規則引擎后元模型建立的工作流管理系統具有更強的動態性以及智能性。
2 基于擴展元模型的智能動態工作流模型
2.1 智能動態工作流模型形式化描述
智能動態工作流模型的形式化描述如下。
定義1 IDWFM={V，D，A，E}。式中，V為工作流的版本號；D＝為一個多元組，表示動態工作流一般信息；A為流程中活動的集合；E＝{T1，T2}為一個二元組，E為工作流中可擴展規則的集合；T1等于{α1，α2，。..，αi-1，αi}為流程運行中動態變化活動組成的集合，它可在流程實例運行過程中被動態的選定；T2＝{RR，RA，RP}是流程動態變化規則的集合，式中，RR為路由規則，RA和RP分別為活動屬性更改規則和自已定義規則。
定義2 αi＝{ID，Name，Tyi，Ri，ExA}為工作流活動。式中ID為活動的唯一標志；Name為活動名稱；Tyi∈{Start，End，General Activity，Routing Activity，Auto Activity}為活動類型；ExA={N_Ai，V_Ai|i＝1，2，。..，n}為活動可擴展的屬性集合，N_A為屬性的名稱，V_A為屬性的值。通過定義活動中的可擴展屬性就可以對活動的屬性進行有效的描述。這些屬性是動態可擴展的屬性值，是動態可變的。當Tyi＝General Activity時，Ri為空；當Tyi＝Routing Activity時Rule表示路由規則，當Tyi＝Routing Activity時Rule表示自定義規則。
定義3 e={ID，WFID，Name，Type，AF，AE}用于傳遞兩個業務活動之間的數據信息和控制信息，是連接弧集合E的一個元素；式中，ID為連接弧的標識；WFID為連接弧所屬流程ID；Name為連接弧的名稱；Type為連接弧的類型；Type∈{Static，Dynamic}，Type=Static表示連接弧在建模時建立；Type=Dynamic表示連接弧在流程運行時建立的是一個臨時連接弧；AF和AE分別為連接弧的源活動和目標活動。
2.2 FC系統
傳統的ERP系統工作流產品提供一定的意見路由支持功能。但是它們存在著以下不足：①無法識別動態意見，無法根據流程中的信息項實現流程的動態變化、智能流轉，并且這些只是提供了對意見路由的支持，功能比較單一。②傳統工作流中的路由解析由工作流引擎負責，而且在建立模型的同時，路由規則已經固定好，無法實現規則的動態變化，而且當需求變化的時候，往往要對工作流模型做出調整。③規則的解析由工作流引擎負責，從而加大了引擎的負擔，而且解析器的設計比較固定不容易更改。
基于上述原因，本文中提出一個獨立于工作流系統的流程協調器（FC），FC系統獨立于工作流系統，它與工作流系統共享同一個數據庫，并且通過本身提供的交互接口與工作流引擎進行數據交換，結構如圖2所示。
圖2 FC系統結構
①規則設計器。規則設計器主要負責設計系統中用于約束、限制工作流動態因素變化所必須遵守的規則。當需求變化的時候，可以通過規則設計器修改規則達到對流程的設置，提高系統的柔性。
②意見字典設計器。業務主管簽署的意見必須是計算機可識別的規范化的意見，業務主管只能從這些規范意見中進行選擇，而不能隨意地在意見欄內填寫意見，從而“生產”出計算機無法識別的新意見。因此就必需建立意見字典，它用于存儲意見標志和意見名稱。通過意見字典設計器，可以相機進行添加意見以適應不同審批系統的實際需求。意見字典包含動態意見和路由意見兩種。
③路由規則引擎。路由規則引擎負責解析流程的規則。通過對流程規則的解析完成工作流動態因素的動態更改，包括：流程活動屬性的動態更改、動態添加、刪除流程活動。路由規則引擎通過交互接口完成與工作流引擎的數據交換。通過加入路由引擎可以大大降低工作流引擎負擔，也降低了工作流引擎的復雜度。
④交互接口。交互接口負責與工作流引擎進行數據的交換，它主要包括2個接口。
規則解析接口主要描述FC系統對工作流引擎提供的功能。其中Get Nexe Node Model ID函數主要是用于解析規則得到當前流程下一個活動，輸入的參數分別為當前活動意見、流程模板ID、活動模板ID；EditNode函數負責更改活動屬性，輸入的參數依次為當前活動意見、流程模板ID、活動模板ID；IsHaveRul函數判斷當前活動是否具有解析的規則，如果返回真則表示當前活動具有解析的規則調用上面兩個函數，否則不調用路由規則引擎。
數據提取接口描述FC對外提供的數據獲取功能。其中，Getopinion函數主要是獲取意見列表，參數為流程模板ID.Getrul函數用來獲得某個活動的規則，參數分別為流程模板ID和活動模板ID。以上接口中的函數可以根據需要進行擴展。
2.3 智能動態工作流模型體系結構
智能動態工作流模型結構如圖3所示。
圖3 IDWFM結構
該模型右半部分是工作流管理聯盟提出的工作流參考模型，左半部分是規則協調器。智能動態工作流模型與傳統工作流模型的不同主要體現在任務表管理器工作流引擎，功能說明如下：
①任務表管理器。任務表管理器管理和維護任務表，引用規則協調器（即FC），提供用戶界面，讓用戶便捷地選擇意見。同時還可以自定義規則。用戶在執行提交操作時，任務表管理器將檢查用戶是否完成必要的任務，是否簽署了必要的意見。通過引用FC接口判斷本結點是否具有解析規則。
②工作流引擎。工作流引擎通過FC系統的數據接口與其路由規則引擎進行交互，工作流中的一部分功能將由路由規則引擎負責。工作流引擎接受到任務后將根據條件對任務進行分配，如果當前結點需要對工作任務進行規則的解釋分析，則工作流會把該任務分配給路由規則引擎，并把意見傳送到規則協調器系統，由規則協調器中的路由規則進行解釋分析，解釋分析后把結果回送到工作流引擎，工作流引擎根據結果進行任務的分配。這樣就實現了流程的智能流轉。
從圖3所示的模型看到，協調器系統與右半部分的工作流參考模型是相互獨立的，兩者之間通過數據接口相互聯系，因此當同一個流程應用于其他的部門時，只需要通過協調器系統提供的設計器對意見字典和規則庫進行更新，而不需要通過工作流系統進行更改，這樣既可以非常便捷地實現工作流管理系統的移植，又提高了工作流管理系統的可移植性和通用性。
3 實例
FC系統的運行過程是和工作流引擎交互的過程，通過FC系統提供的數據接口進行數據的交換。本節以一個項目審批流程為例介紹流程動態智能流轉的過程。圖4為一個審批流程的流程圖。
圖4 審批流程圖
該流程的關鍵路徑為：登記一崗位責任人審核一主管處長審核一局長審核一備案。而黨委擴大會議為一個動態活動，它是在流程運行過程中動態添加的。流程中主管處長審核環節的審批時限是動態變化的。
假設審批輸入的信息項如下。
審批項目名稱：爆炸物品生產審批；生產產品：12#工業用炸藥，數量：12t；緊急程度：緊急；意見字典為：同意生產、不同意生產。
審批系統規則包括審批環節和審批規則，其中審批環節有崗位責任人審核和主管處長審核。對應崗位責任人審核規則為：RP＝{1008，002，崗位責任人審核，上級指定規則，IF（超過時限流程自動通過，審批意見為：同意生產）}。對應主管處長審核規則為RA={1009，IF（事項類型為緊急）THEN環節中時限更改為1天}。RR＝{1010，add，IF（意見為同意生產并且物品的數量》10t）THEN增加黨委擴大會議，主管處長審核環節）。
流程運行過程如下。
①當登記人員登記完后，提交申請，工作流引擎首先調用RulExplain中的IsHaveRul函數，函數返回false，這樣FC系統將不進行工作，工作流引擎將負責解析流程模板，把任務發送給崗位責任人審核這個環節的任務處理人員。
②崗位責任人審核的處理人員得到任務后在任務處理界面進行審批，根據信息處理人員選擇的意見為同意生產。如果在規定時限內審批，審批的過程為：提交任務后工作流引擎同樣調用IsHaveRul函數，返回值為true，因此工作流引擎通過調用EditNode函數把任務發送給FC系統的路由規則引擎，引擎根據規則對主管處長審核這一環節的屬性進更改完成后函數返回值為true，并把結果送給工作流引擎，引擎得到返回結果后再次進行任務的分配，把任務發送給下一個審批環節的處理人員。
③主管處長審核這一環節的處理人員得到任務后在規定的時限處理任務，選擇同意生產，這樣工作流引擎通過調用GetNexeNode函數把任務交給路由規則引擎進行規則的解析，得到增加的審批環節的信息并把結果返回給工作流引擎，工作流引擎根據結果把任務發送給新增加審批環節的任務處理人員。這樣就完成了流程的智能動態的變化。
以此類推，流程逐步運行直到流程運行到最后。
流程在運行的過程中根據輸入的信息項和用戶輸入的意見進行智能流轉，自動調整流程的路徑，實現了工作流的動態性以及智能性。
4 結論
通過對原有的工作流過程元模型進行擴展，引入新的元素，提高了元模型在流程動態性的描述。在該元模型的基礎上提出了IDWF模型，該模型通過FC系統對規則的解析實現了流程的動態運行以及智能流轉。此外引入FC系統的工作流管理系統具有很高的通用性和移植性。目前開發了基于IDWFM的動態審批系統并應用于某項目，具有很好的效果。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：基于擴展元模型的智能動態工作流建模方法
相關文章
