企業IT架構轉型之道：阿裡巴巴中台戰略思想與架構實戰. 2.6 改變組織陣型會帶來組織效能的提升

<b>2.6　改變組織陣型會帶來組織效能的提升</b>

如今大多企業的資訊中心部門的職能還停留在“業務支援”的程度，是為企業的業務部門提供it系統支援的組織。這也造成了這些企業的資訊中心部門的員工，更多的是承擔甲方項目經理的職能，很多事情本質上都是偏事務性的工作，也就是這樣的工作并不會随着工作時間的長短而讓人的能力得到持續性提升。這種以項目為導向的方式，使得資訊中心的員工往往一個項目上線後，就會投入到下一個項目的工作中，對員工在業務或專業能力上很難得到持續的積累和沉澱，結果就是員工的積極性和創造力在逐漸被消磨，整個資訊中心部門的生産力和創新氛圍也會受到非常大的影響。

如果企業打造了共享服務體系，一方面會徹底改變現在“煙囪式”系統建設的模式，新的項目都會基于共享服務體系建設，在項目的建設周期和資源投入上會相比之前帶來很大的效率提升，自然資訊中心的員工也無需再投入那麼多的精力負責項目管理的事務，接下來對整個共享服務體系中的這些服務中心進行持續“營運”的職能勢必會落在企業資訊中心這個部門，此時我們就可以将資訊中心部門的員工按照服務中心的方式進行人員組織的重新編排，讓員工在各自擅長和感興趣的業務領域中持續發展，員工的業務了解和專業技能随着對應服務中心所提供業務能力的逐漸完善而同步提升，這樣對于員工的工作積極性和創新意識的提升将會創造一個很好的氛圍。

早期淘寶技術團隊的組織人員組成跟今天企業中資訊中心和技術部門的人員組成幾乎一樣，針對應用系統建設的不同階段對人員的不同的技能要求，整個團隊由幾類人員組成，如圖2-6所示。

使用者體驗設計師——user experience design，職責包括産品界面視覺引導，原型設計，與開發一起推動設計實作。

圖2-6　傳統應用開發模式下技術人員的分工組成

架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目盡量效率高，開發容易，維護友善，更新簡單。總體上架構師是一個既需要掌控整體又需要洞悉局部瓶頸并依據具體的業務場景給出解決方案的人。

開發人員則是具體應用業務邏輯的實作者，具備使用自己掌握的程式設計語言實作業務的需求。

運維工程師更多的是負責應用底層伺服器和計算資源（存儲、網絡、硬體伺服器等）為應用的運作以及穩定運作提供基礎架構的服務。

dba（database

administrator）資料庫管理者主要從事管理和維護資料庫系統的相關工作，負責業務資料庫從設計、測試到部署傳遞的全生命周期管理。其核心目标是保證資料庫管理系統的穩定性、安全性、完整性和高性能。

可以看到整個團隊基本都是擁有較強技術技能的人員組成，每當有從業務部門産生新的應用系統建設或業務需求時，團隊各司其職的人員協同配合，争取最快實作業務需求的滿足。我們可以将整個技術團隊看做成一個組合精密的流水生産線，源源不斷的業務需求進入到這條流水線後，經過流水線上各專業人員的貢獻，最終将業務需求以系統的方式輸出這條流水線。

這樣的方式确實是經過多年軟體工程發展梳理出的一套合理的組織架構，也很好地展現出“專人做專事”的原則以及不錯的系統開發效率。但這樣的方式适合業務服務化後的架構嗎？

流水線方式的弊端是對于不同角色人員的技能持續提升是會出現發展瓶頸的，做了3年的開發人員可能跟做了5年的開發人員可能在開發能力上沒有太大的差別，根本原因就是這兩年的差别僅僅是用自己熟練的技能多“生産”出幾個不同的系統。設想一名技術員工在一個崗位上工作了一段時間（一般2～3年）後，認為在這個崗位上沒有太大的技能提升，大部分工作都是重複的，在這樣的情況下，就很容易出現兩種情況：一類是工作的積極性沒有之前那麼高，得過且過的在本職崗位繼續工作；一類則是看到外面公司有更好的工作機會，選擇了跳槽。不管是哪一類，這兩種情況都将給團隊和企業造成不同程度的傷害。

是以如果繼續采用這樣的方式，各服務中心的需求都像之前傳統的模式輸入到流水線中，因為流水線上各崗位人員每天可能都面臨的是不同服務中心或業務方的需求，很難對各服務中心現有的能力有清晰和深入的了解，是以對于服務中心能力的擴充和更新很難提供最為專業的支撐，自然也會對最後提供的業務需求實作的專業度和穩定性帶來了很大的隐憂。

正是出于這些因素的考慮，阿裡巴巴集團在建構了共享服務體系之後，對于各技術團隊的組織架構也做了如圖2-7所示的調整。

如上圖所示，針對每一個建設的服務中心，從組織架構的形态上也發生了對應的調整，會有不同角色的人員（架構師、開發人員、ued工程師等）組建成了一個新的組織，每一個這樣的組織都針對某一服務中心提供持續的服務能力開發及運維，更準确說是基于這一服務中心的業務能力進行“營運”。

是以在今天阿裡巴巴共享服務體系中的這些服務中心，每一個服務中心都是由一個少則100多人，多則4、5百人的團隊對負責的服務中心進行專業的營運。采用這樣的方式，就很好地解決了之前流水線模式下，不同角色技術人員很難對于某一業務領域有持續的了解和沉澱，而采用圍繞服務能力持續營運建構獨立組織的形态，讓整個團隊對于該服務中心的能力逐漸完善、專業以及穩定負責，在這個過程中，團隊的成員就有了足夠的時間和機會對于該服務相關的業務領域有了更深入的了解，進而為團隊培養出既懂技術，也懂業務的複合型人才建立了良好的生長土壤。

圖2-7　共享服務體系後人員組織的調整

在這樣的一個組織中，最為核心的角色就是業務架構師，在阿裡巴巴共享服務各服務中心的業務負責人一般為此角色，業務架構師的能力模型正是那種典型的即懂技術，也對負責的業務領域有相當了解的。這些架構師一般是從技術開發出身，在多年業務領域的需求浸染中，不斷形成了對該業務全面的知識體系以及自身的了解，對該業務在集團内的職能定位、市場發展趨勢都有一定的全局認識，能從業務的視角帶領團隊朝着服務中心的核心能力打造、專業、成熟的方向前進。

業務架構師即作為整個服務中心業務發展的領路者，也是保障服務中心核心業務保持業務通用性和公共性的最重要的捍衛者。在服務中心與前端應用進行業務的支援和對接過程中，一定會收到來自前端業務方對服務中心能力增加的需求，如果對這些需求不加任何過濾和判斷，都引入到服務中心層面實作的話，勢必會損害服務中心業務的通用性，過多的帶特定業務屬性的需求在服務中心層面實作，導緻的結果就可能是随着不斷業務的對接，服務中心逐漸喪失了他的業務通用性，最終變得對新的業務需求無法提供服務；同時服務中心的業務邏輯過于複雜，在增加了服務中心營運難度的同時，也為服務的穩定性帶來的風險。

當然，以上組織形态并不是金科玉律，在實際發展過程中也會針對業務發展的需求進行适當的調整，以達到業務需求響應以及資源使用率最高。比如我們發現ued前端技術人員本身工作的性質決定了，他們未必需要對所設計的業務有特别深入和持續的了解，進而依然可以采用資源池的方式，将ued相關技術人員組建成專門負責前端互動設計的團隊，為不同服務中心甚至前端應用開發團隊提供專業的ued支援。

最終，通過共享服務體系的建設以及組織陣型的調整，在有效提升員工積極性和創新意識的同時，也勢必讓整個部門的生産力和業務響應效率得到極大的提升。最重要的是讓資訊中心部門從之前在企業中“業務支援”的組織職能，轉變為基于企業核心業務和資料進行營運的團隊，這個團隊會更快、更好地支援業務發展的同時，逐漸掌握企業最核心的業務和資料，逐漸培養出企業最稀缺的“既精通業務，又熟悉技術”的複合型人才。在接下來整個社會進入開放共享的時代，企業最大的價值将會是基于這些核心業務和資料進行對外開放的營運，到那個時候，這個部門将成為企業最為寶貴的資産。