本書關注于IT里的流程產品。面對市場上品種繁多的流程產品，很多人的困惑是：這些流程產品究竟能夠幫助企業做出哪方面的改進，這些產品背后的理論基礎又是什么？同時，很多人對IT產品的宣傳也存在著困惑，最多的就是：工作流技術和BPM（業務流程管理）技術究竟存在著什么區別？為什么很多原先的工作流產品現在都改稱為BPM產品？本書將對這些問題都進行一定的討論，一個事實是IT流程系統將在企業的改進方面發揮越來越重要的作用，但是不可否認的是，就目前而言，這些系統還存在著很多的局限，如果一個流程產品的思想是流程自動化，那么很大程度上這個產品是不符合企業發展需要的。

提到流程，第一個問題就是流程的歷史。18世紀英國經濟家學亞當·斯密在《國民財富的性質和原因的研究》中提出“勞動分工原理”，提出分工有利于提高效率、增加產量，其理由有三：第一，勞動者的技巧因業專而日進；第二，分工可以免除由一種工作轉到另一種工作的時間損失；第三，簡化勞動和機械的發明使一個人能做許多人的工作。亞當·斯密的分工論蘊涵了最樸素的流程理念。流程產生于一系列的分工。

維基百科里 對業務流程進行了如下定義：業務流程是為特定的對象（客戶）創造價值的過程，這一過程由一系列相關聯、有組織的活動或任務組成。企業和組織中，業務流程一 般被劃分為三種基本類型：管理流程，對企業運行進行管理、協調的流程；運行流程，構成核心業務和創造基本價值的流程，如采購、制造、市場銷售等；支持流 程，支撐管理流程和運行流程的流程，如會計、招聘、技術支持等。

接下來我們關注工作流技術的歷史。工作流技術發端于1970年代中期辦公自動化領域的研究工作，但工作流思想的出現還應該更早，1968年Fritz Nordsieck就已經清楚地表達了利用信息技術實現工作流程自動化的想法。1970年代與工作流有關的研究工作包括：賓夕法尼亞大學沃頓學院的Michael D. Zisman開發的原型系統SCOOP，施樂帕洛阿爾托研究中心的Clarence A. Ellis和Gary J. Nutt等人開發的OfficeTalk系列試驗系統，還有Anatol Holt和Paul Cashman開發的ARPANET上的“監控軟件故障報告”程序。SCOOP, Officetalk和Anatol Holt開發的系統都采用Petri網的某種變體進行流程建模。其中SCOOP和Officetalk系統，不但標志著工作流技術的開始，而且也是最早的辦公自動化系統。

 可以看到，工作流最初出現的思想和要解決的問題即是實現工作流程的自動化。但是這帶來了工作流技術應用的局限：第一是在企業里存在著很多關鍵的業務流程，這 些流程自動化的成本太高，無法自動化；第二是很多流程并不需要自動化，自動化反而會降低這些流程的執行效率，典型的在一個企業里，請假往往需要一定的審 批，在這種情況下，直接面對面的交流往往比通過工作流提交表單更有效率；第三是自動化流程往往意味著流程的柔性降低，比如制造企業都有設備維修業務過程，基本步驟如下：故障維修申請 －> 審批 －> 派工 －> 領料 －> 維修 －> 驗收 －> 維修數據記錄。這樣的一個維修過程如果用工作流實現，工作流引擎會嚴格按照這樣一個順序執行，但是車間隨手換了一個備件，可能只需要5分鐘，而從提交申請到維修結束，走這樣一個繁瑣的過程，恐怕不是信息系統服務于人了，而是人服從信息系統了，再比如，緊急情況下進行的維修，可能直接進行維修、驗收、記錄維修數據三個步驟，可能連派工都來不及了。此時，自動化流程就會嚴重影響執行效率。

1970年 代人們對工作流技術充滿著強烈樂觀情緒，研究者普遍相信新技術可以帶來辦公效率的巨大改善，這種期望不可避免的落空了。人們觀察到這樣一種現象，一個成功 的組織往往會在適當的時候創造性的打破標準的辦公流程；而工作流技術的引入使得人們只能死板的遵守固定的流程，最終導致辦公效率低和人們對技術的反感。1970年代工作流技術失敗的技術原因則包括：在辦公室使用個人計算機尚未被社會接受，網絡技術還不普遍，開發者還不了解群件技術的需求與缺陷。總結一下，工作流應用失敗的原因有兩點：第一點是自動化流程的柔性低；第二點則是限于當時的技術原因。

進入1990年代后，隨著IT技術的發展、個人計算機的普及，工作流技術開始重新進入一個新的熱潮，這個熱潮完全是技術驅動的，這時候出現了大量的工作流技術應用。需要注意的是，工作流技術不僅僅是指專門的工作流管理系統，同時也指擁有工作流特征的各種應用系統，例如各類企業管理軟件（ERP）和協作軟件里有具有的相應流程組件。工作流技術的應用使得很多應用軟件的開發得到一定程度的簡化（同時，可以觀察到工作流產品的采購客戶往往會是系統集成商）。需要注意的是，此時工作流要解決的問題域依舊是實現工作流程的自動化，由此帶來的應用局限并沒有發生變化。

與此同時，新的管理革命正在發生。

1990年邁克爾·哈默在《哈佛商業評論》上發表了題為《再造：不是自動化改造而是推倒重來》(Renglneenllg work：don"t automate，obliterate)的文章，文中提出的再造思想開創了一場新的管理革命。1993年邁克爾·哈默和詹姆斯·錢皮在其著作《企業再 造：企業革命的宣言)(Reengineering the Corporation；a Manifesto for Business Revoiution) 一書中，首次提出了業務流程再造(BPR：Business Process Reengineering)概念，并將其定義為：對企業業務流程進行根本性的再思考和徹底性的再設計，以取得企業在成本、質量、服務和速度等衡量企業績 效的關鍵指標上取得顯著性的進展。該定義包含了四個關鍵詞，即：“流程”、“根本性”、“徹底性”和“顯著性”。

以此為標 志，形成了新的業務流程理念，并伴隨著對傳統企業金字塔式組織理念和管理模式的反思，新的理念強調企業以業務流程為中心進行運作、打破傳統的部門隔閡、增 加客戶價值和企業效益（降低成本）。以業務流程為中心取代職能分工，成為管理的首要原則，圍繞流程建立起來的組織具有更高的敏捷性、效率和效益，呈現出扁 平化、網絡化的特征。

新的管理理念催生新的IT產品，BPM產品孕育而生。可以說一個好的IT產 品總是對應有相應的理論基礎，那種簡單的對現有工作方式的復制化是沒有生命力的（一個小的而典型例子是電子印章軟件，從布局到排版都很逼真。可是現實中印 章的設計是為進行文件的狀態確認，非常直接，但是在電腦上摹仿這種印章，不但用著別扭，看著也十分難過，更重要的是，明明通過工作流的控制已經能夠確認文 件的狀態，卻一定要通過電子印章來生硬模擬。）。很多技術人員以XPDL和BPEL來區分流程產品是工作流還是BPM，認為BPM更為強調軟件的系統集成能力。實際上，工作流軟件與BPM軟件最大的區別不在于技術實現，而是它們解決的問題域發生了變化。

工作流軟件解決的問題域是流程的自動化，而BPM軟件解決的問題則是業務流程的優化。

因為解決的問題域發生變化，那么BPM軟件相比工作流軟件在技術上的變化就很清晰了：強調對流程運行的監控、強調對流程運行數據的分析、強調對各種企業應用軟件的集成能力、強調快速的開發能力。實際上很多BPM軟件的前身即是工作流產品，從技術角度上理解，工作流軟件和BPM軟件是沒有區別的，BPM軟件是工作流軟件發展的結果，只是開發商出于市場的考慮換上一個不同的標簽而已（非常類似于當前的藥品市場，同一種成分換個名稱就變成新藥）。然而從處理問題的角度考慮，區別兩者則又是必要的。

但是BPM軟件面臨的問題依舊存在，因為很多BPM軟件解決問題的思路并不正確，很多BPM軟件依舊是通過自動化流程來實現業務流程的優化，這再次回到工作流軟件所面臨的問題：企業很多業務流程很難自動化、自動化流程的柔性很低。對于這些問題，BPM軟件試圖通過簡化編程（快速開發、SOA思想）和系統集成來盡可能自動化多的流程，通過增強流程定量分析能力來盡可能的增加流程柔性。這實際上是在用正確的方式做錯誤的事，因為解決問題的思路從一開始就決定了這并不是一條正確的路。

相比而言，Nimbus的Control-ES軟件則選擇了另外一條道路，它并不強調流程的自動化，它是從咨詢軟件發展而來的，這決定了其解決問題的另外一種方式：強調對現有流程的評估和重構而非自動化。在Control-ES里，流程是作為企業財產保存的，僅僅文檔化。這幾乎立刻擴大了其對業務流程的描述能力，但是其的咨詢背景也決定了它的局限性：無法實時獲取業務流程執行的數據（完全依靠咨詢人員的工作），于是Control-ES更多是作為咨詢人員的工具而存在的。從某種意義上說，流程改進本來就是一項咨詢工作，很多IT廠商甚至沒有任何業務領域經驗，拿出其BPM軟件就宣傳能夠實現客戶流程的優化是一件很搞的事情，很多所謂的流程梳理實際僅僅是對現有流程的復制再現，沒有任何改進可言。

          一種更好的方式是文檔化所有業務流程，然后通過系統集成能力實時獲得關鍵的數據信息，實現以流程為中心的數據撮合，關鍵的流程執行和改進則交由人去靈活執行。對這種實現思路我們將在本書的最后部分進行討論。可以看見的是，流程優化從來也不應該是IT系統能夠完成的事情，IT系統所要做的是為流程優化撮合必需的數據，做為支撐系統而存在。

          說完BPM軟件，最后我們需要關注的一個方向是云計算。越來越多的企業將其工作放置到了網上，典型的如Google提供的各種在線服務，文檔、郵件、Excel等，這種趨勢觸發了新的業務模式，云中的工作流即是其中一種，通過提供在線的工作流程自動化，將各種在線服務通過流程粘合起來。在這方面，Cordys走在了最前面。

我們知道，一個商業目標的實現必定由一系列 的活動組成，這些活動的編排即構成了以目標為導向的業務流程。管理的目標即通過合理有效的編排這些活動以期以最少的成本達到最大的收益。這個編排的過程亦 即進行業務流程建模的過程。在進行業務流程建模時反復出現的活動結構構造即產生了模式。在本章中，我們將討論工作流的控制模式。控制模式關注業務流程中活 動的編排，一方面強調與實際業務的契合，另一更為重要的方面則是如何合理調配這些活動。

 

本章討論的控制模式共計43種。需要注意的是，這些模式的出發點是基于對實際業務進行描述的，與具體的工作流系統沒有太大的關聯。而一個工作流系統對工作流模式的支持程度則直接決定了該系統對業務的建模能力。所以在某種程度上，衡量一個合適的工作流系統時，往往會考慮其對工作流模式的支持程度。

 

本章討論的控制模式按照描述、應用和實現展開，分別對應著模式的介紹、模式對實際業務的映射和工作流產品對該模式的實現支持。最后是小結。作為約定，我們將業務流程里的活動映射為任務，將對活動的建模描述映射為任務節點。

 

一、       基本控制模式

基本控制模式包括5個模式，是其他控制模式的基礎。

 

1、順序（WCP_01: Sequence）

描述

在同一個流程實例里，任務會在前續任務完成后順序觸發。

圖 4-1

如圖4-1所示，任務A執行完畢后會順序觸發任務B的執行，任務B執行完畢后會順序觸發任務C的執行。

 

同義詞

順序執行、串行路由。

 

應用

順序模式是工作流建模的基礎，是流程定義里最基本的構建塊，用以描述連續串行的一系列任務，這些任務之間的觸發是無條件的。

順序模式也是實際的業務中應用最多的模式， 當實現一個業務價值需要執行多個任務時，最自然的方式就是排序并順序完成這些任務，典型的如流水線作業。當企業人數不多，業務模式簡單（不需要過多的任務 或任務之間存在很強的線性依賴關系），管理成本很低時，順序模式是最自然的選擇。

 

2、并發分裂（WCP_02: Parallel Split）

描述

分支分裂為兩個或多個后續分支，當分支執行完畢后觸發后續并發分支的同時執行。并發的分支有可能在后續合并為一個分支，也可能不合并。

圖 4-2

如圖4-2所示，任務A完成后將同時觸發任務B和任務C的執行，任務B和任務C的執行不存在前后關系。

 

同義詞

AND-split、Fork、并行路由、并行分裂。

 

應用

在傳統的軟件開發里，開發過程被典型的分為了5個階段，如下圖所示：

圖 4-3

這5個 階段是順序執行關系，典型的當需求分析完畢后會有一個需求凍結狀態，在這種狀態下才開始正式的軟件設計和實現。該模式最大的弊端在于在需求分析階段不可能 捕獲用戶所有可能的需求，而且客戶的需求是變化的，開發階段由于需求凍結對于客戶完全黑盒，導致最后的交付無法實現客戶期望的業務價值。

在敏捷開發里，開發過程由多個迭代組成，在每個迭代里，需求分析、架構設計、編碼開發、測試和交付都是同時進行的，客戶參與到這個過程中，客戶能夠從不斷的交付中提出新的需求，這樣軟件才能夠更好的響應變化，不至于在最終交付時出現業務價值的偏差。

圖 4-4

其實從某種角度上看，不同企業的組織管理結構也決定了它所采用的業務流程模式。在圖4-3所 示的開發流程里，每個階段都對應于不同的部門，需求分析有專門的業務部門，開發部門內部分為了架構部門、開發部門和測試部門，交付則又有專門的實施團隊， 在這種情況下，從管理的成本考慮，順序執行無疑是最自然和最便宜的選擇（這也是為什么在傳統企業里實施敏捷困難的原因之一）。

而在敏捷開發團隊里，整個團隊則是圍繞開發流程建立，減少了內部不必要的協調溝通成本，能夠達到相對較高的執行效率。

 

實現

由于后續分支的觸發是無條件的，所以在很多工作流產品的實現里省去了AND-split節點，直接由任務節點進行分支分裂，如下圖4-5所示：

圖 4-5

jBPM使用token記錄當前流程實例執行的位置并觸發流轉，建立起token的父子關系。如下圖所示，在AND-split節點每個并發的分支都會產生一個新的子token，當子token到達AND-join節點后即可通過其訪問到它的父token，再通過父token遍歷其子token即可獲得當前并發分支的執行情況并實現合并。

圖 4-6

作為約定，我們在后續的說明中，將會采用token來指代當前流程實例所執行的位置。

 

3、同步（WCP_03: Synchronization）

描述

兩個或多個分支合并為一個后續分支，當被合并的分支都執行完畢后，后續分支才被觸發。

圖4-7

如上圖所示，當任務A和任務B都完成后，才會觸發任務C的執行。

 

同義詞

AND-join、匯聚、同步。

 

應用

在實際的應用中，AND-split節點與AND-join節點一般成對出現。

在任何時候，總結總是有必要的，每次迭代開發結束后，我們都會進行迭代小結，寫出應該改進的部分、應該保持的部分，以保持整個團隊的迭代前進。

實際上，很多情況下AND-split節點和AND-join節點往往隱含著管理意義，上一級的管理者在AND-split節點進行任務的管理和下發，在AND-join節點對任務執行結果進行負責。

 

實現

和AND-split節點一樣，在部分工作流產品里，直接采用任務節點進行分支合并，如下圖所示：

圖 4-7

jBPM里，分支的合并實際是token的合并，子token生命周期終止，父token重新激活。

 

4、排他選擇（WCP_04: Exclusive Choice）

描述

分支分裂為兩個或多個后續分支，當分支執行完畢后只能選擇觸發一個后續分支執行，即多選一。

圖 4-9

如上圖所示，任務A完成后將會選擇觸發任務B或任務C的執行，任務B和任務C之間只能選擇一個執行。

 

同義詞

XOR-split、排他OR-split、條件路由。

 

應用

流程里的決策任務。會存在兩種決策方式：人為決策和系統決策。由人或一組系統設定條件根據流程執行情況作出后續執行路徑的選擇。

 

實現

兩種實現方式，一種是在XOR-split節點定義路由選擇條件（圖4-10）、一種是在后續轉移線上定義觸發條件（圖4-11）。

圖 4-10

圖 4-11

條件的計算有多種方式：工作流變量與相應條件定義值簡單匹配、提供接口由具體實現類返回計算結果、規則引擎進行規則匹配計算。同時，當存在多個后續分支和條件判斷時，一般會定義一個默認執行分支。

 

5、簡單合并（WCP_05: Simple Merge）

描述

兩個或多個分支合并為一個后續分支，任何一個分支執行完畢后就會觸發后續分支的執行，不需要同步，遵循先進先出的原則。需要注意的是：該模式有個前提條件，即前續分支有且只有一個會執行。

圖 4-12

如上圖所示，任務A或任務B只要有一個完成都會觸發任務C的執行，但是任務A和任務B有且只有一個可以執行。如果任務A和任務B都有可能執行，則變為另外一個模式：多合并模式（WCP_08）。

 

同義詞

XOR-join、排他OR-join、merge。

 

應用

在實際的應用中，為保證該模式的前提條件，一般XOR-join節點與XOR-split節點成對使用。

 

實現

和AND-join節點一樣，因為不需要任何條件判斷，所以在部分工作流產品里，直接采用任務節點進行分支簡單合并，但是需要和AND-join做出區別，如下圖所示：

圖 4-13

6、基本控制模式小結

基本控制模式非常簡單，實現起來也沒有太大的難度。需要注意的是，對于一種模式往往會存在多種實現方式，筆者的建議是：將條件判斷的節點獨立出來，由其負責條件計算和路徑選擇，而任務節點則只關注于實際業務的執行，做到職責分離。例如，AND-split、AND-join、XOR-split和XOR-join節點都會單獨存在。

可以看到：除去AND-split和AND-join節 點，順序、排他選擇、簡單合并模式組合的流程和我們編寫程序的邏輯流程圖非常的相似，也就是這三種模式能夠對程序的邏輯流程圖進行建模。于是一件有意思的 事情出現了：有快速開發平臺產品使用流程引擎來編排程序邏輯。他們的做法是將細粒度的代碼邏輯封裝為運算構件，然后再通過流程的可視化編輯器將這些運算構 件粘合起來。這樣，傳統方式下采用代碼實現業務邏輯的過程變成了畫流程圖的過程。筆者認為這樣的實現存在相當大的弊端，相當不合理。首先，編寫代碼變得復 雜了，明明幾十行代碼能夠實現的邏輯卻需要經過編寫構件、繪制程序流程圖、部署、運行好多步才能實現，編程效率可以想象；其次是代碼的執行效率低，程序的 運行需要經過一次流程定義的解釋才能執行；然后是這種實現完全犧牲了語言自身的特性，面向過程，很難提供代碼級別的單元測試環境，只能提供有限的調試。該 實現實際上是定義了一種簡單的流程語言，通過該流程語言來進行功能函數（運算構件）調用的編排。任務編排沒有問題，服務編排也沒有問題，但是如果編排細粒 度到功能函數，那么就超出了流程引擎的作用域。提升編程效率的最好途徑總是語言而不是工具。

六、自動開始模式

在前面的資源模式里，我們討論了創建模式、推模式和拉模式，它們實際對應著工作項的一個正常生命周期：創建、提供/指派、資源選取開始執行。在前面的討論里，工作項的執行都是由資源驅動的（從工作項待辦列表里選取執行），而自動開始模式則提供了一種系統驅動工作項執行的方式，系統直接驅動工作項執行往往表明了該工作項的最高優先級，需要馬上開始執行。

圖 5-42

如圖5-42所示，自動開始模式對應著紅線標識著的工作項的狀態變遷，共有4種模式：創建即執行、指派即執行、成堆執行和鏈式執行。

 

1、創建即開始執行（WRP_36: Commencement on Creation）

描述

資源能夠在工作項一創建完畢就開始執行。

圖 5-43

如圖5-43所示，任務A工作項一創建就插入員工甲的辦理列表，需要員工甲馬上開始執行。

 

應用

該模式應用在關鍵的優先級高的任務里，通過系統推送，強制資源優先執行該任務，省去任務的等待時間。

 

實現

該模式的實現實際是系統同時完成了工作項的創建和推送，系統需要確定具體的執行人，工作項不會分配給角色、崗位等資源組以提供給相應資源進行選擇。

 

2、指派即開始執行（WRP_37: Commencement on Allocation）

描述

資源能夠在工作項一指派完畢就開始執行。

圖 5-44

如圖5-44所示，任務A工作項一旦被員工甲從可拾取列表拾取就馬上插入員工甲的辦理列表，需要員工甲馬上開始執行。

 

應用

該模式跳過了工作項的指派狀態，實際是對創 建即開始執行模式的擴展，在創建即開始執行模式里，工作項必須預先確定明確的執行人，不能分配給角色、崗位等資源組，而在該模式里除了支持創建即開始執行 模式里的情況，同時也提供了對這種情況的支持，工作項可以提供給多個資源拾取，一旦一個資源拾取則必須馬上開始執行（從這個角度看，該模式與資源驅動執行-提供工作項模式是相同的）。

 

 

3、成堆執行（WRP_38: Piled Execution）

描述

資源能夠成堆執行相同任務的不同工作項。

圖 5-45

如圖5-45所示，員工甲有多個任務A的工作項需要執行，這些注意的是，這些工作項并不是由一個任務實例所產生的，它們屬于不同的流程實例，是由多個流程實例里的任務A生成的。一旦員工甲開始任務A工作項的執行，那么他將執行所有任務A的工作項，即將任務A相關的工作項全部打包執行。這一功能由系統驅動，系統將與任務A相關的工作項依次推送至資源的辦理列表。

 

應用

開發人員甲熟悉持續集成工具，此時同時有多個軟件開發項目需要搭建持續集成環境。一旦他為某個項目組搭建了持續集成環境，那么處于執行效率的考慮，最好的方式無疑是他一鼓作氣將所有的持續集成環境都搭建完畢。

相同/相似的工作交由同一資源一并執行，這些工作具有完全或大部分相似的執行上下文（相同的知識、能力要求），從這個角度能夠達到最高的工作效率。

 

實現

系統需要在進行工作項狀態變遷操作時提供相應的鉤子，以進行相應的回調操作。

 

4、鏈式執行（WRP_39: Chained Execution）

描述

在一個流程實例里，當前一個任務的工作項執行完畢后，能夠自動開始執行下一個任務的工作項。

圖 5-46

如圖5-46所示，任務A和任務B是兩個連貫的任務，它們都分配給員工甲執行，當員工甲執行完畢任務A的工作項后，任務B生成的工作項將馬上被系統發送至員工甲的辦理列表，員工甲需要馬上辦理。

 

應用

該模式實際是將資源膠黏在一個流程實例上，同樣是出于執行效率的考慮（兩個任務位于同一流程實例里，具有相同的執行上下文）。該模式的應用具有前提條件：流程定義時，連續的任務由相同的資源進行處理。

 

七、可見性模式

可見性模式討論各種不同資源對工作項的可見 性，不同的資源由于角色、權限的不同，對工作項擁有不同的可見范圍。由于涉及到權限，那么根據不同的組織機構設置，必然會出現不同的工作項權限分配，這里 不討論具體的工作項權限分配，僅從工作項的狀態來討論這些工作項區分可見性的必要性。

可見性模式包括2種：未指派狀態工作項的可見性和指派狀態工作項的可見性。實際上，工作項處于執行狀態或完成狀態也存在不同的可見性。

 

1、可配置的未指派工作項的可見性（WRP_40: Configurable Unallocated Work Item Visibility）

描述

能夠配置未指派工作項的可見性。

圖 5-47

如圖5-47所示，可拾取列表里存在3個工作項：任務A工作項、任務B工作項和任務C工作項。員工甲可拾取的工作項包括：任務A和任務B工作項；員工乙可拾取的工作項包括：任務B和任務C工作項，那么由此產生的可見性是：員工甲只能看到任務A和任務B工作項，而員工乙則只能看到任務B和任務C工作項。而作為員工甲和員工乙的部門經理，他需要了解每個屬下的工作情況，所以他可以看見所有甲乙可見的工作項。

 

應用

隨著企業規模的發展，幾乎所有企業的組織模 型都會形成金字塔型的結構，一方面是出于分工的需要，另一方面則是出于管理的需要，每一層級的人員都需要對上一級負責，同時管理下一層級的人員。處于管理 的需要，管理者必然需要了解下屬的工作情況，這樣權限就自然產生了，具體到工作流的任務里，管理者需要對其所管理下屬的工作具有可見性。

其實不僅僅是對于工作項，對于流程實例本身 也具有可見性的分配。對流程負責的人必然具備最大的可見性和權限，流程根據任務分解，如果僅僅只對某一任務負責，那么則只對該任務具有可見性，而如果需要 對多個任務負責，那么就需要對多個任務具有可見性，最直接的負責人就是具體執行該任務的人員，但是引入管理的層級后，職責的承擔也會形成層級的關系，從上 至下層層承擔，此時擔負最大職責的人員往往不再是具體的工作執行人員，而是相應的管理人員。

 

實現

在前面所描述的情況里，支持員工甲乙的可見性是比較簡單的，因為每條工作項記錄都攜帶有參與者信息，但是部門經理顯然不在這些參與者信息里，所以需要引入與組織權限模型相匹配的工作項查詢機制，即不同于工作項列表的查詢列表。

 

2、可配置的指派工作項的可見性（WRP_41: Configurable Allocated Work Item Visibility）

描述

能夠配置已指派工作項的可見性。

圖 5-48

如圖5-48所示，待辦列表里存在3個工作項：任務A工作項、任務B工作項和任務C工作項。指派給員工甲的工作項包括：任務A和任務B工作項；指派給員工乙的工作項包括：任務C工作項，那么由此產生的可見性是：員工甲只能看到任務A和任務B工作項，而員工乙則只能看到任務C工作項。而作為員工甲和員工乙的部門經理，他需要了解每個屬下的工作情況，所以他可以看見所有甲乙可見的工作項。

 

八、多資源模式

到目前為止，我們討論的工作項都是與某一特定資源一一對應的，即一個工作項只能由一個單一資源執行，或者嚴格來說，一個工作項在任何時間段都只能由一個單一資源執行（考慮到工作移交的情況）；同時，一個資源在任何一個時間段都只能處理一個工作項。

多資源模式將會討論兩種不同的情況：一個資源同時執行多個工作項、多個資源執行同一個工作項。

 

1、同時執行（WRP_42: Simultaneous Execution）

描述

資源能夠同時執行多個工作項。

圖 5-49

如圖5-49所示，員工甲的辦理列表里有三個工作項，他能夠同時執行這三個工作項。

 

應用

和計算機一樣，雖然在任何時刻都只能處理一項工作，但是通過將多項工作切分成多個線程交替執行，從某個時間段看，人能夠同時處理多項工作。

人能夠選取相關聯的多個工作，同時開始執行，在執行的過程中，合理安排這些工作的執行時機和順序。

 

實現

幾乎所有的工作流系統都不會約束人員往自己的辦理列表里增加多個工作項。

 

2、增加資源執行（WRP_43: Additional Resources）

描述

資源能夠要求增加資源來處理他正在執行的工作項。

圖 5-50

如圖5-50所示，員工甲和員工乙同時處理一個工作項。

 

應用

在一些復雜的場景里，一項工作往往需要多個資源共同協作完成。

典型的在一個會簽任務里，一個發文需要多人簽字通過，同時在會簽過程中，經常出現動態加簽的情況：需要新的人員加入進行簽字。

在敏捷開發里，所有的開發工作都是由兩個開發人員共同結對完成。

 

實現

工作項作為工作流系統里最小的工作單元，如果將其分配給多個資源，無疑會增加編程模型的復雜度。最常見的實現方式是增加工作項，一個任務節點對應多個工作項，對于需要增加資源的情況，增加工作項。

 

九、小結

在本章里，我們討論了工作流的43種資源模式，這些模式分為7類，分別是創建模式、推模式、拉模式、折回模式、自動開始模式、可見性模式和多資源模式。

創建模式在系統創建工作項時生效，其位于工作項生命周期的創建階段，創建模式作為流程模型的構成部分在流程設計期指定，通常在任務節點的定義里進行定義，與一個任務關聯，其用來限定可執行該任務的資源范圍。系統根據創建模式限定的資源范圍生成工作項。

接下來，系統需要將工作項推送給相關的資源進行執行，這個推送的過程即是推模式所包含的內容。工作流系統通過工作項管理器即不同類型的工作項列表與用戶進行交互，這里的推送可以理解為系統將生成的工作項推送至相應資源的工作項列表里。

推模式的主語是系統，由系統將工作項推送至資源的工作項列表，那么，接下來的主動權交由單個資源本身，由其拉動工作項的執行，這是拉模式所包含的內容。

實際工作中，工作的執行狀態不可能總是與預想相符的，總會出現各種各樣的情況，例如重新分配、重做、掛起等等。折回模式對應著這些情況，折回代表著工作項狀態的反復、回退。

自動開始模式提供了一種系統驅動工作項執行的方式，系統直接驅動工作項執行往往表明了該工作項的高優先級，需要馬上開始執行。

可見性模式討論各種不同資源對工作項的可見性，工作項自身作為資源與權限相關。

多資源模式討論一個資源執行多個工作項和多個資源執行同一個工作項的情況。

從這些模式的討論可以看出，這些模式更多關 注的是對實際業務執行的場景描述，關注通過合理分配任務和調配工作的執行為組織帶來最大的執行效率。從另一個角度看，由于這些模式都以業務作為出發點，這 給工作流系統的實現帶來了復雜性，很多模式當前的工作流系統都無法完全支持或直接支持。在很多情況下，模式的支持需要很多的約束，而這種約束往往需要在工 作流實施階段結合客戶具體情況進行限定，這實際強調了工作流實施的重要性，工作流系統的應用是由工作流產品加實施兩部分組成，很多時候，實施占據了更大的 比重，這就對工作流產品的可擴展性提出了要求。應用工作流不僅僅是選擇工作流產品，更重要的還包括選擇合適的實施團隊。

在下一章里，我們將討論另外一種工作流模式-數據模式。

五、折回模式

實際工作中，工作的執行狀態不可能總是與預想相符的，總會出現各種各樣的情況，例如原本分配給員工甲的任務由于甲要請假不得不重新分配，由于新的緊急任務員工乙當前的工作需要掛起一段時間等等。折回模式則剛好對應著這些情況，折回代表著工作項狀態的反復、回退。

圖 5-33

如圖5-33所示，折回模式對應著紅線標識著的工作項的狀態變遷。這些狀態變遷對應著以下情況：

委派：資源將先前指派給他的工作項委派給他人執行。

系統重新分配：系統將沒有完成的工作項重新提供或指派給其他資源執行。

退回指派：資源撤銷指派給他的工作項，工作項可以重新指派給其他資源。

工作移交：資源將其已經開始執行的工作項移交給他人執行。

掛起/恢復執行：資源臨時掛起當前執行的工作項，并在某一個時候重新恢復執行該工作項。

跳過：資源選擇跳過指派給他的工作項的執行，不執行該工作項。

重做：資源重新執行先前已經完成的工作項。

提前執行：資源在流程實際觸發該工作前已經開始執行該工作。

折回模式共有9種。

 

1、委派（WRP_27: Delegation）

描述

資源能夠將先前指派給他的工作項指派給另外的資源執行。

圖 5-34

如圖5-34所示，委派對應于紅線標識著的工作項狀態變遷。

 

應用

委派在平常工作中非常常見，例如員工甲將要請假，他將他要完成的工作委派給同事乙執行；在協同辦公里，領導將相關工作委派給下屬執行等等。

 

實現

實際應用中，委派按照粒度分為了兩種：一種 是工作項的委派，這是一種細粒度的委派，指單一任務實例的委派，與某一特定的任務實例關聯；另一種是業務的委派，這是一種粗粒度的委派，例如，員工甲將其 負責的某類業務的工作全部委派給員工乙，這意味著屬于這類業務的所有工作都將由員工乙執行。業務的委派通常與權限緊密關聯，實際實現時為避免用戶權限的混 淆，一般采取分開登錄系統的方式進行實現，即員工乙如果想處理員工甲委派給其的工作，則需要用員工甲的賬號和其給定的密碼重新登錄系統，并注銷掉自己賬號 的使用。

需要注意的一點是：委派意味著原先指派的資源還必須對該工作負責，例如員工甲將某項工作委派給員工乙執行，盡管員工乙實際執行了該工作，但該工作仍然必須由員工甲負責。所以在實現中，員工甲必須能夠保持對委派工作項的追蹤和控制。

 

2、系統重新分配（WRP_28: Escalation）

描述

系統能夠重新分配已經分配的工作項，以加快工作項的執行。

圖 5-35

如圖5-35所示，工作項原先提供或指派給了一個或多個資源執行，現在由于各種原因，需要優化該工作項的執行，所以將該工作項收回重新分配，提供或指派給其他的資源。

 

應用

工作分配的優化。很多時候，計劃跟不上變 化，工作也是這樣，分配工作前有許多的考慮因素，例如個人能力、工作經驗、技能要求等等，但在實際工作中往往會發現原先的人力分配并不合理，或者有些人承 擔了太多的職責，或者有人能力超出其目前擔承的職責等等（在敏捷軟件開發里，我們通過頻繁的交換結對編程以達到部分的平衡），在這種時候就需要對工作進行 靈活的重新分配以到達最高的執行效率。

 

實現

實際實現中非常受限，對流程的優化始終是一 個對人的命題，而不是對機器對工具的命題，工具所能做到的只是盡可能多的提供可供參考的數據模型，例如各種報表、數據分析等等，最后做出決策的還是人。所 以該模式的實現也以提供給流程管理員重新分配工作項的能力為主，同時提供工作項超時的提示為輔。

 

3、退回指派（WRP_29: Deallocation）

描述

資源撤銷指派給他的工作項，工作項可以重新分配給其他資源。

圖 5-36

如圖5-36所示，資源能夠退回原先指派給他的工作項，該工作項可以交由系統重新分配給其他資源。

 

應用

同樣是工作分配的優化，只不過該模式由資源驅動。

實際工作中，由于各種原因，例如經驗不足、當前承擔職責過多等等，發現自己并不能很好完成當前的任務時，可以提出不執行該任務。

 

實現

實現的難點在于資源退回工作項后的重新分配，即如何重新分配該工作項。

與提供給多個資源模式對應，該模式的最簡單支持是退回重新提供給多個資源。例如工作項分配給開發人員這一角色執行，開發人員甲拾取了該工作項（故事卡），經過一番痛苦和彷徨，最終將該工作項退回，這樣所有開發人員又都能拾取該工作項。

 

4、有狀態工作移交（WRP_30: Stateful Reallocation）

描述

資源將正在執行的工作項移交給其他資源執行，該工作的狀態將得到保存。

圖 5-37

如圖5-37所示，資源將已開始執行的工作移交給其他資源執行。該模式與委派模式很相似，差別就在于委派模式是將未開始執行的工作進行重新指派執行，而該模式則是將已開始執行的工作進行重新指派執行。委派模式中的委派者仍需要為委派出去的工作負責，而移交則同時意味著責任的移交。

 

應用

工作移交非常常見，最常見的原因包括位置調動、離職、休假等等。

 

實現

在大多數的工作流系統實現里，業務數據與流程數據是相互隔離的，僅僅通過某一字段進行關聯（例如業務主鍵），流程的目標是攜帶業務數據進行流轉。在這種情況下，該模式的實現變成了默認實現，系統不需要做任何回退或清理操作，直接做工作項的轉發即可。

 

5、無狀態工作移交（WRP_31: Stateless Reallocation）

描述

資源將正在執行的工作項移交給其他資源執行，該工作的狀態不會得到保存。

與有狀態工作移交對應。

 

應用

工作的無狀態移交通常意味著工作的重新執行，并且原有的工作對重啟的工作而言沒有太大的價值。

 

實現

與有狀態工作移交相比，該模式需要處理相應業務數據的回退或清理。直接支持該模式比較困難，需要在實施時根據情況對該任務節點操作業務數據的權限進行限定，并在限定的基礎上進行記錄和回退。

 

6、掛起/恢復執行（WRP_32: Suspension/Resumption）

描述

資源能夠掛起當前執行的工作項，并在某一個時候重新恢復執行該工作項。

圖 5-38

應用

資源對分配給其的工作進行優化執行，能夠根據自己和當前的實際情況合理的安排工作執行，掛起正在執行的工作，執行當前最重要或效率最高的工作，然后再返回執行該工作。

 

實現

基本的狀態變遷。

 

7、跳過（WRP_33: Skip）

描述

資源能夠選擇跳過指派給他的工作項的執行，不執行該工作項，并將該工作項標識為完成。

圖 5-39

 

應用

實際工作中，對于非關鍵工作，可以選擇跳過，以便進行后續更為緊急或重要的工作。

 

實現

對于實現工作項本身的狀態變遷來說，支持該模式非常簡單，問題在于業務數據的依賴關系，如果后續工作的處理依賴于該節點處理后的業務數據，那么簡單的選擇跳過該工作項的執行就會產生問題。所以一個好的做法是給一些關鍵任務節點加上約束，不允許執行跳過操作。

 

8、重做（WRP_34: Redo）

描述

資源能夠對先前完成的工作項重新處理，同時，該工作的后續工作項（后續任務所對應的工作項）也將被重新處理。

圖 5-40

 

應用

對已完成的工作進行重新處理并不少見，但該 模式最為重要的部分還是在于要求所有后續工作的重新處理。所以該模式一般應用在極其重要的關鍵任務節點，例如非常重要的決策節點，因為后續的任務嚴重依賴 于該節點所作出的決策（所產生的數據），一旦決策發生變化，那么相應的后續工作必須都要做出變化。這也是業務敏捷性的一種反映。同時需要注意，該模式也是 一種代價高昂的應用，因為這往往意味著該業務流程實例中的很多工作都需要重新處理，所以如何在業務處理中盡早發現可能的環境變化并及時作出決策的調整并避 免成本高昂的返工才是最為重要的一點。

現在的軟件開發越來越強調于擁抱變化，強調 代碼的重構和演進，盡管如此，如果軟件的基礎架構需要根據當前業務變化發生重大變更，那么這依舊是一件成本高昂的事情，因為一旦基礎架構發生變化，那么很 多模塊實現將不得不重新編寫代碼。所以盡管越來越多的開發團隊開始引入敏捷的開發方法，但是經驗豐富的開發人員才是整個敏捷團隊的基石（敏捷開發非常重視 人）。

 

實現

從該模式里能夠看到資源模式與控制模式的結合，工作項的重做需要后續任務的重新執行，這需要取消當前的執行任務，并將流程實例的控制點重新返回至該工作項所對應的任務。這涉及到兩種控制模式，分別是：取消任務模式和任意循環模式（具體可以參考第四章的說明）。

 

9、提前執行（WRP_35: Pre-Do）

描述

在工作項實際提供或指派給資源執行之前，資源已經可以執行該工作項。

圖 5-41

如圖5-41所示，任務A還在執行，任務B還未激活，但此時員工甲已經可以開始執行任務B的工作項。該模式的實現需要一個前提條件：任務B不能依賴于任務A的執行結果，即不能依賴于前續任務的處理輸出。

可以看出，該模式與前面推模式里的提前分配模式非常相似，所不同的是：提前分配強調一種通知機制，強調預先準備；而提前執行則已經可以開始實際的執行工作。

 

應用

和提前分配模式不同，該模式實際提供了一種 流程任務執行的靈活機制，在預先定義的業務流程里，任務的執行是具有一定順序的，可能在大多數情況下，這種順序是合理的，但是在某些具體的流程實例里，某 些串行執行的任務節點可以并行的執行以達到最好的執行效率和負載均衡，在這種情況下，就可以應用該模式并行執行部分任務。

需要注意的是，該模式僅僅引入了一種實際執行任務的靈活性，是對業務流程定義固化的補償，如果在一個業務流程中頻繁應用到該模式，則往往意味著流程定義本身需要作出調整。

本書全文連載地址
四、拉模式

與推模式相比，拉模式的區別在于動作的主語發生了變化：推模式的主語是系統，由系統將工作項推送至資源的工作項列表，那么，接下來的主動權交由單個資源本身，由其拉動工作項的執行。

圖 5-28

如圖5-17所示，拉模式對應著工作項的五種狀態變遷：

由提供給一個資源拾取到指派給一個資源負責執行，這意味著該資源拾取了該工作項，其將負責該工作項的執行，并將在未來的某個時候執行該工作項；

由提供給多個資源拾取到指派給一個資源負責執行，這意味著多個資源中的一個資源拾取了該工作項，其將負責該工作項的執行，并將在未來的某個時候執行該工作項，余下的資源將不再有機會執行該工作項；

由提供給一個資源拾取到開始執行，這意味著該資源拾取了該工作項，其將負責該工作項的執行，并立即開始執行該工作項；

由指派給一個資源負責執行到開始執行，這意味著該資源開始執行該工作項；

由提供給多個資源拾取到開始執行，這意味著多個資源中的一個資源拾取了該工作項，其將負責該工作項的執行，并立即開始執行該工作項，余下的資源將不再有機會執行該工作項；

拉模式共有6種，分為兩組：前三種模式關注工作項的狀態變遷；后三種模式關注工作項顯示在資源工作項列表里的順序以及選擇執行的方式。

 

1、資源驅動指派（WRP_21: Resource-Initiated Allocation）

描述

資源能夠將工作項指派給自己，負責該工作項的執行，但是不必馬上開始執行該工作項。

圖 5-29

如圖5-29所示，員工甲拾取了可拾取列表里的任務A工作項，該工作項由可拾取列表移至待辦列表。可拾取列表通常是一個共享的列表，而待辦列表則是某一資源的專屬列表。資源拾取工作項，意味著工作項從共享狀態進入到專屬狀態。

該模式實際對應著工作項的兩種狀態變遷：由提供給一個資源拾取到指派給一個資源負責執行；由提供給多個資源拾取到指派給一個資源負責執行。

 

應用

該模式符合大多數的工作場景，我選擇負責執行該工作，但我并不馬上開始，我可能還有其他的工作需要處理，等到處理完畢后才處理該工作。

 

實現

分配給角色、部門等資源組的工作項通常都以共享的形式分配給所有的組內成員，一旦有人拾取即進入他的專屬待辦列表，其他人不再可見。

 

2、資源驅動執行-指派工作項（WRP_22: Resource-Initiated Execution – Allocated Work Item）

描述

資源能夠開始執行指派給其的工作項。

圖 5-30

如圖5-30所示，員工甲開始執行任務A工作項，該工作項由待辦列表移至辦理列表。

該模式對應著工作項的一種狀態變遷：由指派給一個資源負責執行到開始執行。

 

實現

最基本的工作項狀態變遷，所有的工作流系統都提供支持。

 

3、資源驅動執行-提供工作項（WRP_23: Resource-Initiated Execution – Offered Work Item）

描述

資源能夠選取提供給其的一個工作項，并馬上開始執行該工作項。

圖 5-31

如圖5-29所示，員工甲拾取了可拾取列表里的任務A工作項并立刻開始執行，該工作項由可拾取列表移至辦理列表。

該模式對應著工作項的兩種狀態變遷：由提供給一個資源拾取到開始執行；由提供給多個資源拾取到開始執行。

 

應用

與描述略有不同，實際應用該模式是強制要求資源一旦拾取了共享的工作項就必須馬上開始執行，基于兩點的考慮：一是工作項能夠盡快執行；二是工作項能夠指派給當前最為空閑的資源，不會出現該工作項被一繁忙資源卡住，造成等待和阻塞。

在敏捷開發里，我們使用故事卡管理項目的開 發，故事卡足夠小（如果大的故事卡則分解為多個任務），每天早上由開發人員挑選移動該卡，一旦該卡由可開發狀態移動至開發狀態，則必須進行該卡的開發工 作，這樣項目的真實進展隨時得到顯示，同時不允許一個開發人員同時進行多張卡的開發。

 

實現

通過這三個模式我們可以發現，工作流系統實現這些模式只是在不同的工作項列表里移動這些工作項，以反映工作項不同的狀態和變遷策略，這對于IT系 統而言這不是很困難，困難在于如何能保證人確實是這么做的，例如說一旦拾取就必須開始執行，工作項的跳轉很簡單，但無法保證的是拾取該工作項的人一定會按 照要求馬上開始執行該工作項，也就是說業務流程項目的實施不僅僅包含技術實施，也包含了一套與之相應的管理實施。那種期望上一套流程系統就能馬上提高生產 效率和管理水平顯然是不現實的，其中一定包含管理方式的變化和組織機構的變化。

敏捷開發中，早上的站立會議是重要的部分，每個團隊成員都會匯報昨天的進展和今天將要進行的工作，這樣就保證了工作執行的有效性。

 

4、系統決定工作隊列內容（WRP_24: System-Determined Work Queue Content）

描述

工作流系統能夠排定資源工作項列表里的工作項順序和內容。

圖 5-32

如圖5-32所示，員工甲共享的可拾取列表默認按時間排序工作項。

 

應用

實際應用中工作項的排序條件非常多，其目的就是將最重要或優先級最高的工作項排在最前面，引起資源的注意或優先執行。

 

實現

實際實現時有多種排序策略，通常會有時間排序，例如先進先出、先進后出等，同時也有很多其他的排序元素，例如工作項的預定完成時間、執行該工作項的成本預算、工作項的優先級或重要程度等，系統查詢工作項時根據這些影響因素進行默認排序。

 

5、資源決定工作隊列內容（WRP_24: Resource-Determined Work Queue Content）

描述

資源能夠排定其工作項列表里的工作項順序和內容。

 

應用

為資源提供一定程度上排定工作項的靈活性。每個人關注的視角和側重點不同，就會產生不同的排序和內容過濾。

例如，作為老板，我可能更為關注各個工作的成本預算，我需要按成本排定各項工作；而作為秘書，我更為關注老板下發各項工作的重要程度，我需要按老板指定的重要程度排定工作。

 

實現

提供工作項列表的客戶端排序，一般情況下列表顯示系統給定的順序，用戶可以在客戶端進行二次排序，典型的Web系統中，工作流系統提供JavaScript的表格控件，利用Ajax異步請求重新排序或進行工作項的過濾。

 

6、自主選擇（WRP_26: Selection Autonomy）

描述

資源能夠根據自己個人的情況選擇執行工作項。

圖 5-32

如圖5-32所示，員工甲能夠根據自己的情況選擇執行任務A、B、C中任意一個工作項。

 

應用

盡管老板要求先實現功能最后再重構，但是我認為當前代碼如果不進行一定重構會嚴重影響后續的開發效率，所以我決定先進行部分重構。

 

實現

幾乎所有工作流系統都不會對用戶實際選擇執行工作項的方式進行限制，也沒有辦法限制。但是系統一般會把重要的工作項加以高亮顯示，讓用戶優先選擇。