組織結構涉及兩個基本要求：一方面要把某個創造價值的活動拆分成不同的活動，另一方面又要將各項活動協調整合起來，以便實現最終目標。
在附錄A裏，我們討論了工作流控制模式，即組織結構的第一個基本要求，強調對業務流程進行建模，將商業目標的實現根據組織所進行的工作和現有的技術體系拆分成一系列的活動。這裏將接着介紹工作流的資源模式，活動協調的本質其實是組織內部資源的協調，即滿足組織機構的第二個基本要求。
活動的執行需要資源，資源的協調對業務流程執行的效率非常重要，對顧客而言，流程執行的時間越短則越有效率。
什麼是資源呢？
人是最重要的資源，除了人之外，還有其他的非人力資源，如機器、設備、計算機等。資源最根本的特徵是：它能夠執行特定的活動。
一個資源只能執行有限種類的活動。反過來，一個活動通常也只能被有限種類的資源所執行，這涉及資源的分組。組織對資源的分組具有多種形式，最常見的是部門和角色：部門體現資源在組織中的位置，角色體現資源的業務職能。對跨國跨地域的組織而言，還有地域機構的劃分，此外還有臨時組，例如以交付爲核心的軟件開發公司裏的項目組。
爲保證流程中每個活動都由合適的資源執行，我們在活動建模時定義分配規則，該規則說明執行該活動資源所需要符合的前提條件和約束。分配規則可以直接指定到特定資源（直接分配到具體的人執行），也可以是多個資源分組的交集（例如銷售部的經理），還可能依賴於活動/流程實例本身屬性（例如對於北京地區提交的貨物訂單會交由北京配送中心進行處理），此外，還有其他一些考慮，例如爲安全考慮，銀行任何職員不能執行同一流程實例中兩個連續的活動，會計學裏稱之爲職能分離。我們會在後面的資源模式裏詳細討論這些情況。
在工作流系統裏，活動在運行期被映射爲工作項（work item），活動的執行被映射爲工作項的執行。一般情況下，一個活動在一個流程實例中只對應一個工作項，但是存在一個活動需要多人完成的情況，這個時候一個活動就會對應着多個工作項。工作項是工作流系統中最小的工作單元，其代表着一個單一資源對某一活動的執行。工作流系統裏，資源與工作項的交互通過工作項管理器進行管理，即我們通常所見的工作項列表（任務列表），我們通過這一列表拾取工作、處理工作以及管理工作的狀態。
工作項的生命週期
工作項的生命週期具有8個狀態，分別是創建（Created）、提供給一個資源拾取（Offered Single Resource）、提供給多個資源拾取（Offered Multiple Resources）、指派給一個資源負責執行（Allocated）、執行（Started）、完成（Completed）、失敗（Failed）和掛起（Suspended），如圖B-1所示。
圖B-1 工作項的生命週期
工作項被系統創建完畢後即處於創建狀態，接下來系統會選取資源來執行該工作項。有兩種狀態：一種是被提供狀態，一種是被指派狀態，這兩者的區別在於對資源來說一個是可選的一個是必須的。如果系統提供一個工作項給資源執行，這僅僅意味着資源符合執行該工作的前提條件，資源不必爲該工作負責，即資源可以選擇執行該工作也可以選擇拒絕，資源只是該工作的合適候選者；而如果系統指派一個工作項給資源執行，則意味着資源必須爲該工作負責，該工作必須由該資源執行。因爲一個工作項只能由一個資源來執行，所以如果是指派的話，那麼只能指定一個資源；而提供，則可以提供給一個資源也可以提供給多個資源來候選。工作項管理器提供兩種列表來區分這兩種狀態，分別是可拾取列表和待辦列表，一旦資源對可拾取列表裏的工作項進行拾取，工作項即進入到資源的待辦列表，狀態成爲被指派狀態。
工作項進入被指派狀態意味着執行該工作的資源已確定，那麼接下來就可以由資源開始執行該工作，執行的過程中可以將工作暫時掛起中斷處理，後續可以再恢復對該工作的執行。如果工作成功完成，則工作項成爲完成狀態；如果工作因爲各種原因沒有成功完成，則工作項置爲失敗狀態。
工作流資源模式的分類
工作流資源模式共有43種，根據工作項所處的不同階段以及狀態變遷，分爲7組，即創建模式、推模式、拉模式、折回模式、自動開始模式、可見性模式和多資源模式，如圖B-2所示。
- 創建模式位於工作項生命週期的創建階段，作爲流程模型的一部分在流程定義期指定活動的分配規則，限定執行該活動的資源範圍；
- 推模式將創建完畢的工作項與滿足分配規則的資源進行匹配，將工作項推送給資源，源本身不做出選擇；
- 拉模式則是資源把工作項與自身進行匹配，考察其能夠執行的工作項並選擇執行，資源是主動的；
- 折回模式對應着由於各種原因所導致的工作項狀態的反覆和回退；
- 自動開始模式提供一種系統驅動工作項執行的方式，表明工作項的高優先級，需要馬上開始執行；
- 可見性模式討論各種不同資源對工作項的可見性，與管理權限相關；
- 多資源模式討論一個資源執行多個工作項和多個資源執行同一個工作項的特殊情況。
圖B-2 工作流資源模式的分類
分組是協調組織內部工作的一種不可或缺的手段，其最重要的作用就是建立起一套普遍的監督體系，每個單位都會指定一名管理者，由其對該單位的所有行爲負責，這些管理者又會相互聯繫，從而建立起組織的權力體系；其次，分組通常要求單位裏的人員共享相同的資源，如硬件機器；最後，分組可以鼓勵同一單位內人員的相互調節（即通過非正式的簡單溝通實現對工作的協調），因爲大家在同一個地點工作，又共用公用設施，如廁所，使得大家彼此接近，促進了經常性的非正式接觸。
分組帶來的最大問題就是：促進了組內協調，卻犧牲了組外協調。步兵瑞科就曾憤憤地抱怨：他們就知道在天上飛，我們卻在下面送死。（《銀河艦隊》）作爲開發人員的我們也曾經抱怨過：他們就知道提需求，反正也不用自己開發。
組織分組的標準
那麼，組織分組的標準有哪些呢？有以下4個：
- 工作流相依性；
- 工作方法相依性；
- 工作規模相依；
- 社會相依性。
工作流相依性
許多針對特定操作活動之間關係的研究，都着重指出了這樣一個結論：對操作活動的分組應該反映出工作流的自然相依性。例如，圖B-3所示是一位作者對紡織廠中連續生產工序“自然”和“不自然”的看法。以工作流相依性爲基礎的分組，單位成員會有一種領土完整的感覺，他們支配着一個定義明確的工作流程，工作中所出現的大多數問題，都可以通過彼此的相互調節而得到輕易的解決。相反，如果一個定義明確的工作流程分解到若干不同單位來完成，那麼協調起來就困難了。組織要求各單位之間能夠相互合作，可實際上，單位之間很難進行良好的合作，所以，一旦出現問題，必須呈交給遠離工作流程的上級管理者來解決，而這些上級管理者由於遠離實際的工作流程，往往會根據下級彙報做出決策，於是決策的有效性可想而知（參見明茨伯格的《卓有成效的組織》）。
圖B-3 根據工作流對紡織廠的“自然”與“不自然”分組
那麼，根據工作流相依性分組的最優解和最差解分別是怎樣的呢？我們以軟件開發流程來進行說明。如果一個單位的職能能夠涵蓋整個完整的工作流程，則是最優解。在這種情況下，工作中的大部分問題都能在單位內得到解決。如圖B-4所示，開發流程中的大部分工作都能在一個團隊內完成，這個團隊包含了BA、開發人員、測試人員等多種角色的成員，所以也被稱爲全功能團隊或閉環團隊。
圖B-4 工作流相依性分組最優解
由工作流相依性重新思考組織分組由來已久。1990 年，邁克爾·哈默在《哈佛商業評論》上發表了題爲“再造：不是自動化改造而是推倒重來”的文章，文中提出的再造思想開創了一場新的管理革命。以此爲標誌，形成了新的業務流程理念，並伴隨着對傳統企業金字塔式組織理念和管理模式的反思，新的理念強調企業以業務流程爲中心進行運作、打破傳統的部門隔閡、增加客戶價值和企業效益（降低成本）。以業務流程爲中心取代職能分工，成爲管理的首要原則，圍繞流程建立起來的組織具有更高的敏捷性、效率和效益，呈現出扁平化、網絡化的特徵。
然而，重新思考圖B-4所示的全功能團隊我們會發現，在很多情況下，在最低層級組建上圖所示的全功能團隊並不現實（什麼是最低層級？意思是該單位不會再有下級單位），出於溝通效率的考慮，一個單位的成員不能夠無限擴大，在傳統的管理書籍中（法約爾），這個約束甚至被建議爲5人。在很多製造型企業裏，這個人數實際上是大大超出這個限制的，原因就在於標準化。
然而，在知識密集型企業裏，因爲並沒有一致的標準能夠遵循，單位成員之間必須面對面溝通以協調彼此的工作，那麼單位規模必須足夠小，小到便於所有成員能夠做到適宜、頻繁和非正式的溝通。所以，對於一個軟件項目而言，一個小於10人的全功能團隊是最適合的，一旦團隊規模超過20人，那麼就必須進行再分組。對很多軟件開發而言，他們需要的人數遠超20人，那麼這種最低層級上的全功能團隊就不再適用。
如果工作流程上的各個單位構成順序依賴的關係，則是次優解。在這種情況下，每個單位僅僅對其上一個單位產生依賴，單位之間的協調較少。如圖B-5所示，可以看出這是一個典型的以職能進行分組的組織，這樣的分組至少看上去並不壞，但是現實卻是：這是一個相當沒效率的分組。原因就在於該分組基於一個重要的假設：開發流程中的活動是可以分階段完成的即瀑布開發模型。現實中，這個假設卻是完全不成立的，這些活動聯繫的如此之緊密，以致於在這些單位之間不得不時時發生大量的協調。於是該分組實際是圖B-6的樣子，最差解！
圖B-5 工作流相依性分組次優解
如果工作流程上的各個活動需要跨越多個單位進行反覆協調溝通，那麼則是最差解，稱之爲交互式相依，如圖B-6所示。在我們觀察過的一個組織裏邊，測試人員發現軟件缺陷後的第一反應不是走過僅僅一屏風之隔的開發小組裏進行溝通，而是先填寫在線的缺陷跟蹤系統，然後再打開即時消息工具，給開發人員發消息：有缺陷，缺陷號是xxx。組織在進行分組時，必須尋求將協調和溝通的成本降至最低。
圖B-6 工作流相依性分組最差解
工作方法相依性
即使用相同工作方法的人員分到一個單位，通常也就是職能分組。這種分組的好處在於能夠激發方法的互相交流，也就是專業性，同類專家分到一起之後，他們能夠互相交流，提高各自的專業水平。在現在公司裏，經常能夠看到不同團隊成員之間的非正式交流，這裏，其實是公司整體的文化氛圍爲這種交流提供了便利。實際分組時，需要在工作流相依性和工作方法相依性間做出權衡。
規模相依性
第三個標準與經濟規模有關。考慮這樣一個例子，軟件的測試需要真實的硬件環境進行模擬，而這些硬件比較昂貴，那麼一個最經濟的方式就是成立專門的測試部，統一購買一批硬件，統一對所有的軟件進行上線前測試。同理，由於DBA比較昂貴，公司不可能爲每個團隊都配備一名，所以DBA不屬於任何團隊，其是共享的。
社會相依性
第四個標準與具體的工作沒有關係，與人的社會性有關係。如果領導沒有頭暈，他是絕對不可能將兩個水火不容的人放置到一個單位內的（帝王除外，那叫帝王術）。以上就是組織進行分組的4種標準。歸納一下：如果工作流相依性意義重大而又難以納入標準的話，那麼組織就應該嘗試以市場（項目）爲基礎進行分組，這樣便於相互調節和直接監督；如果工作流不規則，標準化能夠涵蓋工作流相依性，如果方法和規模相依性意義重大，那麼組織應該積極尋求專業化，以職能進行分組。
最後，我們討論一下大規模軟件團隊的分組.在上面我們提到，一旦人員規模超過20人，那麼最低層級上的全功能團隊就不再適用，就有必要進行再分組。如何進行再分組呢？圖B-7所示是某IT企業的多層級分組，實際上最重要的是開發部門的按特性分組，每個開發小組都必須能夠獨立交付產品的一個特性。注意，這裏是交付，既然是交付那麼就不僅僅包含開發一個活動，還需要包括需求分析與測試，這樣，從某種意義上，該開發小組實際構成了全功能團隊，實際中，每個開發小組都包括了系統分析人員、開發人員與測試人員。
B-7 某IT企業的多層級分組
開發部門按照特性交付分爲多個開發小組後，整個產品由一個個模塊構成，新的問題出現，就是系統的集成問題，這裏的集成問題實際反映出各個開發小組之間的協調問題。此時，一個獨立的測試部門和持續集成就是必須的了，從某種意義上理解，測試部門實際上着重解決的是各個模塊間的相互影響以及系統作爲一個整體的完整測試，從持續集成的角度考慮，此時最重要的自動化測試應該應用在各個模塊之間交互的部分。