二、創建模式

創建模式在系統創建工作項時生效，如下圖所示，其位于工作項生命周期的創建階段。

圖 5-2

正如上面提到的，工作流系統在執行任務節點時會為其創建相應的工作項，根據情況工作項可以是一個也可以是多個。

創建模式作為流程模型的構成部分在流程設計期指定，通常在任務節點的定義里進行定義，與一個任務關聯，其用來限定可執行該任務的資源范圍。系統根據創建模式限定的資源范圍生成工作項，工作項可以直接分配給人，也可以分配給角色、部門、崗位等。

 

1、直接分配（WRP_01: Direct Distribution）

描述

在設計期直接為任務指定特定的資源，該任務的工作項能夠在運行期分配給它。注意，指定的資源可以為多個，如果是多個的話就會生成多個工作項，為每個資源生成一個單獨的工作項。該模式實際限制執行該任務的資源范圍。

圖 5-3

如圖5-3所示，任務A在定義時直接指定給員工甲，任務B在定義時直接指定給員工乙，當實際執行任務A和任務B時，將由員工甲和員工乙分別執行。

 

應用

該模式一般應用于流程里的關鍵路徑。同時， 在中小企業里，該模式是應用最多的分配模式，因為人員少，管理扁平，所以每個人的職責都非常清晰。該模式也是執行效率較高的資源模式，因為人和任務直接綁 定，所以不會產生推諉等情況，便于管理也便于追究責任，因為運行情況完全在設計期確定。而隨著企業規模的擴大，管理層次的復雜，一個任務往往需要交由特定 的部門、崗位或角色來執行，這樣無形中會影響任務執行的效率。

該模式的缺點在于一旦關鍵人物因為各種原因不能及時處理任務，那么將造成整個流程的掛起等待。

 

實現

最簡單的資源模式，設計期確定資源，運行期工作流引擎不需要做額外的工作。

 

2、基于角色的分配（WRP_02: Role-Based Distribution）

描述

在設計期為任務指定一個或多個角色，該任務的工作項能夠在運行期分配給這些角色。實際執行該任務時，資源將從屬于這些角色的資源中產生。該模式實際限制執行該任務的資源范圍。

圖 5-4

如圖5-4所示，任務A在定義時指定給“開發人員”這一角色，該角色包括了兩名員工甲和乙。實際執行任務A時，將由員工甲或乙來執行。

 

應用

企業達到一定規模，就會產生人員的分組，角色是典型的分組方式，將具有相似屬性的人員定義為一個特定的角色，這些屬性通常與工作的內容相關，例如開發人員、項目經理、總經理等，而角色通常又會與權限產生關聯。

將任務分配給角色意味著將會有多個員工可以執行該任務，執行效率相比直接分配會有下降，這也是企業擴大后管理成本增大的一種表現形式。

 

實現

工作流系統內置的組織機構模型需要對角色進行支持。引擎運行期通過角色訪問屬于該角色的人員。

 

3、延遲分配（WRP_03: Deferred Distribution）

描述

在設計期為任務指定資源的標識，典型的，在工作流系統里，該標識對應于一個數據字段變量，例如userid。即在設計期并不確定資源，資源的確定被延遲至運行期，系統運行期從該數據字段里獲取該任務分配的資源。

圖 5-5

如圖5-5所示，任務B在定義時資源的標識指定為userid，實際執行時，任務A由員工甲執行，其指定了下一任務的執行者為員工乙即設置了userid這一變量為員工乙的id，在任務B實例創建時，它訪問userid，發現該變量里是員工乙的id，于是將該任務分配給員工乙。

需要注意的是，根據具體的分配策略，運行期該數據字段不僅可以指定人員，也可以指定角色、部門等。

 

應用

該模式給資源的分配引入了靈活性。資源的確定延遲至運行期，即任務可以根據具體的實際情況再確定執行人。具體實施時，這個指定的數據字段可以通過一系列的規則運算得出。

在國內應用中，該模式被大量應用在人工干預流程中，例如下一任務的執行由上一任務的辦理者指定。

 

實現

一般通過工作流變量來包含資源的id。為了區別該id是人員id還是角色id，一般內置特殊變量，例如userid、roleid、groupid等。

 

4、按權限分配（WRP_04: Authorization）

描述

能夠指定資源的范圍，只有該范圍內的資源才具有執行該任務的權限。

圖 5-6

如圖5-6所示，只有項目經理才有權限對開發人員申請軟件的要求進行批準。

 

應用

隨著分工的細化，每個人工作內容的不同，必然會產生權限的概念。權限實際代表著對同一件事情，每個人執行工作內容的差別。權限越大能執行的操作越多意味著需要負責的方面越多。

該模式強調通過權限對執行任務的資源加以限定。

 

實現

在大多數的軟件系統中，角色不僅僅代表具有相似屬性的一組人員，同時其也是最重要的權限概念，人員往往不與權限直接關聯，角色將人員與權限兩者進行關聯。所以，對任務設定權限可以通過指定角色來完成。

 

5、職責分離（WRP_05: Separation of Duties）

描述

在一個流程實例里，能夠指定兩個任務必須由不同的資源執行。

圖 5-7

如圖5-7所示，任務A和任務B在設計期被指定不能由相同的資源執行，同時它們都指定分配給經理這個角色。那么在運行期，在一個流程實例里，任務A被分配給了員工甲執行，那么在進行任務B的分配時，盡管員工甲也屬于經理，但是將不能由其執行。

 

應用

職責分離，不能既當運動員又當裁判員，不能又當跳水隊領隊又當全運會裁判長。

典型的報銷流程里，一般員工的差旅報銷由財務人員核實，但如果某名財務人員需要報銷差旅費顯然不能由自己審批，需要另外一名具有同樣權限的財務人員審核。此時就可以對申請任務和審核任務兩個任務節點應用該模式。如下圖所示：

圖 5-8

 

實現

后續節點進行任務分配時，需要獲取與之關聯前續節點的分配執行信息。流程定義期，在定義任務節點屬性時建立兩者的關系。

 

6、流程實例整個處理（WRP_06: Case Handing）

描述

在一個流程實例里，所有的任務都能夠分配給同一個資源執行。

圖 5-9

如圖5-9所示，流程實例中的所有任務都由同一個人執行：任務A、B、C都由員工甲執行。

 

應用

在應用該模式的流程里，通常流程里的任務都 是緊密關聯的。流程里的任務往往執行在一個緊密相關的上下文里，如果所有的工作都由一個人執行，那么在其了解該上下文的情況下連貫執行這些任務會具有更高 的效率；而如果執行任務的過程中換人，那么新換的人無疑還需要時間對該流程實例相關的上下文進行熟悉，這樣無疑會多付出執行成本。

同一個軟件的開發最好由同一撥開發人員完成，如果中途更換開發人員，那么新來的開發人員需要一段時間熟悉該軟件，會對開發進度產生影響。同樣的道理，在軟件上線前增加開發人員不一定會提高開發效率，很多時候甚至作用相反。

 

實現

可以在實現延遲分配模式的情況下實現該模式，即在第一個任務節點初始化設置參與者變量，后續任務全部使用該變量。如下圖所示：

圖 5-10

 

7、經驗獲取（WRP_07: Retain Familiar）

描述

在同一個流程實例里，當存在多個資源都能執行某一工作項時，能夠將該工作項分配給執行了前某一工作項的同一資源。

圖 5-11

如圖5-11所示，任務A和任務B在設計期被指定由相同的資源執行，同時它們都指定分配給經理這個角色。那么在運行期，在一個流程實例里，任務A被分配給了員工甲執行，那么在進行任務B的分配時，任務B依舊由員工甲執行。

 

應用

該模式剛好與職責分離模式相反，正如它的名字所暗示的，這些任務之間存在著緊密關聯，如果執行了其中一個，那么就會熟悉這些相關聯任務的背景上下文，積累一定經驗，那么后續任務的執行相對其他人來說會變得容易。提高任務執行的效率。

圖 5-12

如圖5-12所示，在軟件銷售的過程中，售前和編寫標書是重要的兩步，這兩個任務最好由同一個人進行處理，因為參與軟件售前的人更熟悉客戶的實際情況和需求，如果分開由不同的人員執行，那么必然會存在前者與后者的交流成本。

 

實現

后續節點進行任務分配時，需要獲取與之關聯前續節點的分配執行信息。流程定義期，在定義任務節點屬性時建立兩者的關系。運行期可以通過參與者變量（工作流變量）建立起運行期關系。

 

8、基于能力的分配（WRP_08: Capability-Based Distribution）

描述

能夠基于資源的能力進行工作項的分配，能力作為組織模型的一部分建模為資源的屬性。

圖 5-13

如圖5-13所示，任務A需要交與開發人員執行，同時其對辦理該任務的人員能力提出了要求，要求只有熟悉JAVA且工作經驗大于2年的開發人員才能執行該任務。這樣就縮小了選取資源的范圍。

 

應用

人力資源管理中很重要的一點就是要做到人盡 其用，每個人的能力都能得到最大的發揮，其實也就是根據能力將人放置到最合適的工作中去。從這一點看，該模式是對人盡其能的實現。但是如何定義各個人員的 能力，這本身就比較的主觀，執行各項工作需要具備的能力也具有主觀因素，更何況很多時候能力并不能與表現劃上等號，模型是固定的但人是變化的受環境影響 的，所以工具本身就是工具，工具的應用最后還是依賴于人。

 

實現

實現需要兩部分：一部分是組織機構對人進行建模時需要包括能力模型；另一部分是流程建模時需要給任務定義執行該任務所需的能力約束，這些約束是一系列的領域特定條件，需要有特定的解析器進行條件的解析。

很多工作流引擎提供有參與者接口，接口返回人員ID列表供給任務分配，從而將這部分工作委派到工作流實施時實現。

 

9、基于歷史的分配（WRP_09: History-Based Distribution）

描述

能夠基于先前的工作歷史決定當前任務的分配。

圖 5-14

如圖5-14所示，當需要在員工甲和員工乙之間做出選擇時，會選擇此前執行類似任務時完成最好的員工。需要注意的是，這里的歷史不再是限定在同一流程實例的任務執行里，可能是同一流程模型的執行歷史，也可能是不同流程模型的執行歷史。

考慮歷史時，有很多的考慮因素，例如完成類似任務最好的員工、完成類似任務最快的員工、完成類似任務出差錯最少的員工等等。這些考慮因素依賴于具體的任務內容和背景。

 

應用

國家籃球隊比賽前，主教練會考察各個位置里各個球員的聯賽比賽歷史情況，其中不僅會考慮出場時間也會考慮各項數據，從而做出選擇。

 

實現

同基于能力的分配模式一樣，該模式的實現依賴于工作流具體應用的場景，也就是需要到實施階段結合實際實現。從某一種角度也說明，應用工作流產品時，產品實施階段也是最重要的步驟，選擇工作流產品不僅僅是選擇產品也需要考察其背后的實施團隊。同時也可見，這些模式在諸如政府OA這些應用中是根本應用不上的。

實現需要兩部分：一部分是對用戶任務執行歷史進行統計分析找出關鍵的評定因素；另一部分是流程建模時需要給任務定義執行該任務所需的歷史因素約束，這些約束同樣是一系列的領域特定條件，需要特定的解析器進行解析。

 

10、按組織分配（WRP_10: Organizational Distribution）

描述

能夠基于人員在組織機構中的位置以及與其他人員的關系分配工作項。

圖 5-15

如圖5-15所示，審批任務需要由申請人的部門經理執行，即需要員工甲的部門經理執行。這種情況即基于人員之間的關系分配工作。

基于人員在組織機構中的位置分配即需要在工作流模型里建立起與用戶相匹配的組織機構模型，可以將任務分配給部門、角色、臨時組、崗位等。

 

應用

應用最為廣泛的模式，實際工作中幾乎所有的工作都必然和組織機構具有聯系。其他模式，如基于歷史的分配、基于能力的分配等都是基于該模式之上的擴展，直接分配、基于角色的分配則直接是該模式的簡單情況。

 

實現

對該模式的支持實際上是對用戶組織機構模型的支持。正如前面所提到的，很難存在一種工作流產品能夠支持所有的組織機構模型，但是大部分的產品都會提供一套元模型或擴展機制，需要在實施過程中最大限度的契合客戶業務。

 

11、自動執行（WRP_11: Automatic Execution）

描述

任務的執行能夠自動完成，不需要人員參與。

圖 5-16

如圖5-16所示，請假審批后需要將情況通知給申請人，該任務由計算機完成，不需要人的參與，也不會產生工作項。

 

應用

隨著自動化水平的提高，越來越多的工作可以交由計算機或相應的機器設備完成。流程中的自動執行節點也會逐漸增加。

 

實現

實際上工作流產品對該模式的支持即是支持各種的企業集成方式，不管是通過Web服務還是消息，工作流需要驅動相應的設備機器或應用系統進行工作并傳遞給必須的數據。所以也可以看出，隨著信息化程度的提高，目前工作流應用越來越趨向于企業集成領域。這也是為什么基于Web服務編排的BPEL會逐漸取代XPDL成為工作流流行標準的原因之一。

http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）