编译文章——ITIL组织架构——如何使用ITIL最佳实践指导组织架构建设（二）（编译 AMT 张纯棣）

ITIL组织架构

——如何使用ITIL最佳实践指导组织架构建设（二）

编译：AMT 张纯棣

服务提供经理（Service Delivery Manager）

“扮演”这一角色的职员要负责所有与服务提供有关的活动——其中大部分活动都需要有很强的主动性才能完成，还有一些活动则需要较长时间的规划。

测试经理（Test Manager）

ITIL中指出我们有必要对某些模块进行独立的测试，但却没有给出具体进行测试的时机。根据实践经验来看，最好将测试经理设置在服务提供部门之中，被服务提供经理所领导。因为这样，这一职务就可以与变更模块建设以及发布管理功能向区别开来（尽管在一些小规模的组织中，测试的职务常常与发布管理相集成）。

服务级别经理（Service Level Manager）

这一角色要负责管理服务级别协议（Service Level Agreements, SLAs）以及运营级别协议（Operation Level Agreements, OLAs），有时还需要承担一部分供应商管理的职责（尽管某些组织可能选择将供应商管理作为一个独立的功能，或者偶尔会涉及一些采购的职责）。有些组织可能还设置了客户关系管理或客户管理的角色（详细内容请见第二部分Additional Roles），这些职务在服务级别协议评估会议以及服务质量反馈会议上都会起到一定作用。

可用性以及能力管理经理（Availability and Capacity Manager）

这两个角色有很强的联系，而且常常被捆绑到同一个架构位置中，但是在一些较大的组织中，这两个角色需要划分清楚。在较小的组织中，可用性和能力管理的职责可以由IT服务连续性管理以及问题管理经理共同承担（但最好的做法还是将它们都依附在服务提供模块下）。在实际的操作中，某些日常的能力和可用性管理职责可以委托给支持团队来完成。由于ITIL要求能力管理经理负责保持所使用新技术的时效性，在某些大型的组织中，可能会设置一个技术架构师（Technical Architect）角色来完成这一任务。

IT服务连续性管理经理（IT Service Continuity Manager）

这一角色要在总体上负责整个IT服务的连续性，最理想的做法是该角色同时也是组织业务连续性团队的一员。如前面所述，在小型的组织中，这一角色可以和可用性以及能力管理相捆绑。如果组织内还在遵循着一些安全规范（如，BS7799），那么此角色也可以与安全管理相集成。

财务经理（Financial Manager）

这一角色要负责所有的财务控制职责，包括财务预算，IT会计以及相关的付费事项。采购或购买角色一般都在此财务经理的领导下，这也是为什么有些看似不需要行政管理支持角色的小组织中仍需要设置这样角色的原因。

请注意，在一些小组织中，这一角色可能会直接向IT领导报道，他因此也会承担一些额外的职责，包括财务规划以及开发团队的管理等。

开发经理（Development Manager）

这一领域实际上已经在ITIL的范围之外——因此应用开发和支持并没有包含在此图中——同样，项目经理也没有包括在内。有些组织可能希望在应用开发之外设置一个应用支持功能——这一职位可以设置在服务管理部门内，另外，对于该职位来说，若想保持岗位技能的先进性，“轮岗”可以说是一个非常好的方法。

有些组织还专门指派了一个角色负责与开发经理的联系，同时也负责将新的IT系统“过渡到使用阶段”的任务。

额外的角色（Additional Roles）

下文中还列出了一些额外的角色，这些角色可能对某些组织的架构来说也是需要的。我们同时也给出了在什么位置上可以设置这些角色的建议。

战略经理（Strategy Manager）

一般较大型的组织可能希望考虑战略经理这个角色，该职位应能承担一部分IT战略制定的责任，向IT领导报告，对其负责。

会计经理/客户关系经理（Account Manager/Customer relationship Manager）

这一角色可以说是IT与业务的联系点。一些较大型的组织可能希望为每个主要客户都安排一个独立的会计/CRM经理。如果组织架构中存在这样的岗位，那么一些被服务级别管理经理完成的任务，如报告，评估等都可以由这一岗位的人员完成。

由于客户对组织的重要性，建议将CRM经理的职位设置在较高的层级上，这样他就可以承担更多服务台的职责，也可以作为日常IT服务与客户沟通的借口。

安全与审计（Security & Audit）

不像可用性管理中的那些小的模块，安全与审计并没有在ITIL中有具体详细的叙述。如果一定要在组织架构图中加入安全经理的岗位，最好将这一职位作为一个独立的功能设置在服务提供部门，或者将他们与可用性管理模块的功能相捆绑，由可用性管理经理来承担安全管理的部分职责。

IT架构师（IT Architect）

这一角色要承担起规划并定义整个组织技术基础设施架构的责任，这也涉及到一些定义组织使用的技术标准的职责。也正因为如此，对该岗位的人员要求也非常高，他们既要了解各种技术，从微观上把握各种技术的优势与缺陷，了解IT基础设施；同时，他们也要从宏观上以一个更加概括、全面、总体的角度来看待整个基础设施架构，从全局的角度考虑问题是该职位的必备能力。在某些情况下，他们还需要承担起评估新技术适用性的责任，因此，他们也需要对新技术了如指掌。

特殊项目（Special Projects）

有些组织有时对一些特殊项目的员工有需求。如果这些员工无法从现有的资源（现存项目、小组、团队）中寻找，那么有必要设置一个独立的角色或功能。同样，这一角色也最好在服务提供部门。最理想的做法是，任何特殊项目都有其一套规范的项目管理流程来管理，也同样受项目管理办公室控制和监督。

合同/采购经理（Contracts/Procurement Manager）

这一职位应受财务管理经理的领导，特别是当财务管理经理位置较高时更是如此。采购与配置管理之间实际上存在着一定的联系——以确保所有采购来的新资产都有相应的标签来标识，也都被记录在配置管理数据库（Configuration Management Database，CMDB）中。

应用过渡经理（Transition to Live）

在应用开发的周期中，有许多时候需要考虑如何将正在开发的应用投入到实际运行环境中的问题，即要考虑在实际中，此应用是否适合？会如何运作？会遇到什么特殊问题和情况？等等。这些问题实际上都涉及到了应用开发这个部门，应由该部门专门派人负责，确保所有问题都被彻底考虑并解决。这一岗位应该有能力做好系统实际运行前的所有准备工作（比如培训员工，使员工熟悉系统，突发事件的分类、诊断，校验各种代码，进行已知错误录入等等工作）。

引入新的架构（Introducing New Structures）

除非有明确且强有力的原因证明做出一些激烈的变革对组织是有帮助的，否则不建议采取“彻底抛弃旧架构，引入新架构”的方式。要知道，不断地进化、演变要比彻底性的革命更柔和，杀伤力也更小，因此也更适合大部分的组织。所以，在变革时期，要循序渐进。有必要将引入新架构的计划公布于众，在实际引入前要分配好各种角色以防措手不及。另外，要为员工留有足够的时间进行培训和准备——既包括技术上的准备也包括心理上的准备，因为，一个组织架构的变化往往会涉及到许多岗位和人员的变化，这对于员工的心理来说是一个很大的考验。要逐渐的、按阶段地实施变革，按这种做法所产生的混乱与不一致现象基本上可以被消除。（3050字）