2.6 改变组织阵型会带来组织效能的提升
如今大多企业的信息中心部门的职能还停留在“业务支持”的程度，是为企业的业务部门提供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支持。
最终，通过共享服务体系的建设以及组织阵型的调整，在有效提升员工积极性和创新意识的同时，也势必让整个部门的生产力和业务响应效率得到极大的提升。最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。
