文李艳杰

ISO/IEC 20000-1∶2011《信息技术 服务管理 第一部分：服务管理体系要求》解析 系列五：ISO/IEC 20000-1∶2011 第7-9章解析

文李艳杰

7 关系管理

7.1关系管理过程综述

关系管理描述的是两个相关方——供应商管理和业务关系管理。管理应保证客户满意度的级别设置合理，未来的业务需求经过互相沟通和理解。业务关系管理中的范围、角色、责任应被明确定义，应包括利益相关方、联系人以及沟通频度等内容。

7.2业务关系管理

目标：业务关系管理过程的目标在于在客户和服务提供方之间建立并维护良好的业务关系。这个过程是建立在对客户和其业务理解的基础上的。

业务关系管理在于对服务进行定期的评审。及时了解客户对于服务的满意度和建议，处理服务投诉。以下是对这三方面的具体说明。

7.2.1 服务定期评审过程

服务提供方和客户应进行服务评审，一年至少一次、以及在重大变更前后。评审应回顾之前的服务绩效、讨论当前与规划中的业务需求、提议服务范围的变更和SLA(Service Level Agreement,服务级别协议)。其他利益相关方，如分包合同商、客户、用户群及其他代表可以邀请参加。

服务提供方和客户也可以开展临时的会晤，讨论阶段进展、成果和事件。这些会议也应有计划表并通知相关利益方。

服务提供方应计划和记录所有的正式会议、议题记录以及随后的协定措施。

服务提供方应建立与客户之间的关系，以便了解他们的业务需求和重大改变，并能够做相应的准备。

7.2.2服务投诉处理过程

对服务投诉的处理应当通过正式的程序进行，并经由内部投诉环节来使投诉获得处理并及时同投诉者沟通，维护客户对服务提供方的满意度。

服务提供方和客户应对投诉过程确认一致，确保投诉的形成和处理没有异议。服务提供方应指定一个过程来采取合适的活动来定位事故。

过程应规定一位服务提供方的联系人作为投诉渠道。

服务提供方应对所有的投诉进行记录、调查、处理、汇报和正式关闭。

重大投诉应通过正规的审核，如在客户认可的期限内未解决，应上诉至上一级管理者。

服务提供方应定期的分析投诉记录，识别趋势，并向客户提供分析报告。

分析报告的结果应被用作服务改进计划的输入。

供应链关系示例图

7.2.3客户满意度测量过程

对客户满意度测量应当形成周期性的正式程序进行，满意度测量的结果可以用于多个方面。比如业务关系处理、服务目录与新产品的更新需求、服务过程评价反馈等方面。客户满意度测量本身为主观测量，需要一定的调查方法以搜集所需的信息。

服务提供方应对客户满意度有测量，并与客户满意度指标及以往调查结果做比较。调查的范围和复杂度应有设计，以便客户可以简单省时的完成。

应对满意度方面的重大差异做调查，了解原因。趋势分析或其他比较只能通过可作比较的问题或样本方法来进行。

满意度调查的结果应与客户做讨论，并达成一份行动计划，输入至服务改进计划，并定时向客户回报进展。对于服务的赞扬应记录，并书面传递到服务实施团队。

7.3供方管理

服务提供者可以将服务管理流程的一部分交由供方去实施和运行。

目标：供方管理过程的目标是将供方服务整合到服务提供方的服务交付当中，以满足客户的约定需求。

对供方进行管理应当同服务提供方同客户约定的服务级别协议相一致。符合于整体的服务要求。

供应商管理过程需保证：供应商理解对服务提供方的责任；以既定的服务水平和范围内满足既定的需求；变更是有管理的；各方之间的交易有记录；各供应商的绩效信息有保留和并合理利用。

供方管理过程的基本活动简要说明如下：

7.3.1服务定义

服务提供方应就实际业务需求来拟定服务需求，草拟对供方在产品、地域、服务质量等方面的要求并形成书面的需求说明；

7.3.2合同管理

服务提供方指派专人负责与供应商的合同和协议。如果有多个员工参与供应商管理，应有一个通用管理过程来保证供应商绩效信息被注意和利用。

服务提供方需有一个规定的联系人负责与每个供应商进行关系管理。

所有供应商合同需包含一张评审计划表来评估一项服务外包对整体业务目标是否持续有效。

需有一个规定明确的合同管理过程，同时包含合同修改管理。这个管理过程的任何修改应告知所有供应商。

需维护好各个组织间（服务提供商与各供应商）的接口清单。如果合同包含赔偿和奖励条款，相关条件应表述清楚并与其他条款保持一致。

服务提供方和供应商都需有一个管理过程来管理合同纠纷，并将其包含在合同中。应保留一条上述渠道，一旦纠纷通过常规渠道无法解决时启用。管理过程应确保纠纷被记录、调查、处理和正式关闭。

合同管理过程需包括合同终止的规定——或者到期终止、或者提前终止。同时，还应包括服务转移到另一家组织的相关信息。

7.3.3供应商评价

结合支撑合同，就供应商的达标情况进行检查。必要时协助供应商一同改进其管理过程，使服务提供方交付的服务能够从整体上满足客户要求。

8 解决过程

8.1事件和服务请求管理

事件的目标：在尽可能小地影响客户和用户业务的情况下使IT系统尽快恢复到服务级别协议所定义的服务级别。这里所指的事件不仅包括软硬件故障，还包括服务请求，访问请求等。

8.1.1事件接收和记录

服务台负责接收和记录事件。它将基本信息输入事件数据库并报告给事件管理小组。事件管理需要给每个事件分配一个唯一编号，记录一些基本的事件分析信息（时间、症状、位置、受影响的服务和用户以及硬件等）并补充其他事件信息（来自于与用户的交互和配置管理数据库等）。

8.1.2归类与初步支持

归类是根据事件发生的原因和所需支持的类别对事件进行划分的过程。归类后确定事件的优先级，以确保支持小组对事件给予必要的关注。优先级应综合事件的影响度和紧迫性来确定。

在确定事件优先级后，服务台应对事件提供初步支持。服务台如果没有成功解决事件，就将事件转交给二线或三线支持处理，然后负责记录事件并协调各支持小组、采取必要的措施以确保用户满意事件的解决过程。

8.1.3启动服务请求程序

如果该事件属于一项服务请求，则启动服务请求程序，由其他服务管理过程如变更过程、配置管理过程、能力管理过程等过程对服务请求进行适当的处理。

8.1.4事件匹配

当服务台接收并记录有关事件的信息后，需要将发生的事件与问题管理中的问题、知名错误进行匹配。如果匹配成功，则可以根据问题管理中现成的解决方案解决事件。如果匹配不成功，则服务台应将事件转交给事件管理人员，由事件管理人员对事件进行调查和诊断。

8.1.5调查和分析

如果没有现成的解决方案，事件管理人员应对事件进行分析和诊断，并提出快速解决事件的方案或应急措施。

8.1.6解决与恢复事件

在确定了事件的解决方案或应急措施后，事件管理人员应当立即对事件进行解决以快速恢复IT服务的运作。

8.1.7跟踪与监控

在事件解决的全过程中，服务台需要跟踪和监控事件解决的进度和用户的反馈情况，必要时应增加事件解决人员或对事件进行升级。

8.1.8终止事件

在事件解决后，服务台应向客户确认事件解决的效果是否达到服务级别协议的要求，如果达到要求或使客户满意则应终止事件，否则应扩展事件处理过程。

8.2问题管理

目标：问题管理指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理过程。其根本目标是预防事件的重复发生。

问题管理过程的基本活动主要包括问题控制、错误控制和主动问题管理。

8.2.1问题控制

问题控制是对发现的问题进行归类、调查和分析从而提出解决方案或应急措施的过程。问题控制的根本目的是要查明事件产生的根本原因，一旦查明事件产生的根本原因，问题就升级为知名错误。知名错误将由错误控制过程解决。

8.2.2错误控制

错误控制是对知名错误进行处理和控制的过程。在问题控制将知名错误转交给错误控制之后，错误控制需要向变更管理提交变更请求，再由变更管理实施变更后最终消除知名错误。

8.2.3主动问题管理

前面所介绍的问题控制和错误控制都是在问题出现后才作出的响应，因而是一种被动的问题管理。事实上，根据对IT基础架构进行的分析，问题管理可以找到可能出现问题的薄弱环节，在事件发生前发现和解决有关问题和知名错误，以尽量减少问题和知名错误对业务的影响。这就是下面要介绍的主动性问题管理。

主动问题管理主要包括两项活动：趋势分析和制定预防措施。

9 控制过程

9.1配置管理

目标：配置管理是围绕IT服务基础架构配置展开的识别、确认配置项，记录监控配置项状态和变更请求、检验配置项的正确性和完整性等活动展开的一系列管理过程。其目标是建立并维护服务组件的完整性，为相关方提供准确可靠的配置信息。

在配置管理中，最基本的信息单元是配置项（Configuration Items，CIs）。所有软件、硬件和各种文档，比如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等都可以被称为配置项。所有有关配置项的信息都被存放在配置管理数据库（CMDB）中。需要说明的是，配置管理数据库不仅保存IT基础架构中特定组件的配置信息，而且还包括各配置项相互关系的信息。配置管理数据库需要根据变更实施情况进行不断的更新，以保证配置管理中保存的信息总能反映IT基础架构的现时配置情况以及各配置项之间的相互关系。配置管理的内容一般包括：

a)配置管理计划；

b)配置标识；

c)确定配置管理范围；

d)确认和记录配置项属性；

e)为配置项定义标识符；

f)确定配置基线和配置结构；

g)确定配置项命名规则；

h)配置项控制和状态报告；

i)配置审计；

j)配置管理数据库备份、存档和保护

9.2变更管理

目标：变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的管理过程。变更管理的目标是对IT服务相关的变更对象进行全生命周期的变更管理，从而使变更可控并最小化风险，将由变更所导致的业务中断对业务的影响减小到最低。

9.2.1记录变更请求

所有的变更请求都应该被记录并分配编号。最好的记录方法是使用集成服务管理系统。这种系统可以自动分配变更请求编号和记录有关变更请求的活动。此外，集成服务管理系统还可进行分级授权，比如任何经授权的人员可以创建、增加变更请求处理报告，但是只有变更管理员或配置管理员有权限终止某个变更请求。

9.2.2评审和筛选变更请求

在记录变更请求后，变更管理人员进行初步评价，以确定是否有不清楚的、不合法的、不切实际的或不必要的变更请求。然后，变更管理人员应根据变更的必要性及其对业务的影响来决定接收或拒绝变更请求。如果拒绝某个变更请求，应说明原因并给变更请求提交者解释的机会。

9.2.3对变更请求进行分类和确定优先级

一旦决定接受某个变更请求，变更管理小组必须确定该变更请求的类别和优先级。

变更管理小组需要根据服务台、事件管理和问题管理等对变更的初步分类，进一步考虑变更的影响和可用资源等方面的情况，最终确定变更的类别。变更类别表明了变更的影响和它对组织所提出的要求，其结构和复杂性很大程度上是由业务需要决定的。

优先级是根据问题的影响度和解决问题的紧迫性确定的，它表明了某个变更请求相对于其他变更请求的重要程度。变更请求的优先级可分为四种：低优先级、中等优先级、高优先级和最高优先级。

9.2.4制定变更实施计划

在明确了变更请求的类别和优先级之后，变更管理小组需要根据变更进度安排表（FSC）对变更实施进行计划。重大变更需要先由IT管理部门批准，然后再提交变更顾问委员会讨论批准。

9.2.5实施变更

在完成前面几项工作之后，变更管理可以开始具体实施变更计划。这个过程主要由建立、测试和实施三个步骤组成。下面对这三项具体的实施活动作简单介绍。

9.2.6建立

在实施变更前需要建立相应的IT组件。建立活动包括的内容包括：

a)建立新的产品模块；

b)创建一个或多个新的软件版本；

c)外购设备或服务；

d)做好准备修复某个硬件；

e)制作新文档或修改补充原有文档；

f)完成撤销（Back-out）计划；

g)准备用户培训修正方案。

9.2.7测试

为了防止变更后的IT组件对服务质量造成不良影响，所有变更在实施前应该接受全面测试。测试的目的主要在于确定IT组件的安全性、可维护性、可支持性、可靠性、可用性等方面的性能。

9.2.8实施

变更的实施不一定由变更管理人员亲自进行，任何部门中的负责基础架构管理的任何人员都有可能被要求对基础架构实施变更。在这一过程中，变更管理的任务是确保这些变更的实施按照变更进度计划表的安排进行，并保证变更对IT服务的影响被降到最低限度。

9.2.9评价和终止变更

变更实施完成后，变更管理小组或变更顾问委员会应对变更实施的情况进行评价。评价主要从以下几个方面进行考虑：

a)变更达到预期目标了吗？

b)客户和用户对变更结果满意吗？

c)变更产生了什么不良影响？

d)变更符合成本效益原则吗？

在针对上述几个问题对变更实施进行评价后，如果认为变更实施成功，变更管理或变更顾问委员会就可以终止变更请求。反之，则要进一步采取行动进行补救，或者干脆撤销（Back-out）现有行动然后提交另一个修改后的变更请求。

9.3发布和部署管理

目标：发布管理负责计划与实施IT服务的变更。其主要目标是通过可控方式将发布项部署于生产环境中，并保证相应的服务级别。其中所谓发布项是指经过测试并导入到实际应用环境的新增或变更的配置项的集合。发布管理是为变更管理提供支持的，发布管理贯穿了变更的整个生命周期，并且发布管理过程的实施应当在变更管理过程的控制下进行。发布管理可应用于设计开发环境、受控测试环境和实际运作三种环境。这其中会同三个库有发生联系。他们分别是∶ 最终软件库（Definitive Software Library，DSL），最终硬件库（Definitive Hardware Store，DHS），配置管理数据库（CMDB）。

（全文完）

作者单位：中国电子技术标准化研究院