信息系统项目管理师考点：IT服务管理的内容与流程分析

IT服务管理（IT Service Management，ITSM）是一套帮助组织对IT系统的规划、研发、实施和运营进行有效管理的方法，是一套方法论。其核心思想是，IT组织（不管是组织内部的还是外部的）都是IT服务提供者，其主要工作就是提供低成本、高质量的IT服务。而IT服务的质量和成本则需从IT服务的客户（购买IT服务的人或组织）和用户（使用IT服务的人）的角度来加以判断。

1. IT服务管理与传统IT管理的比较

IT服务管理也是一种IT管理，不过与传统的IT管理不同，它是一种以服务为中心的IT管理，传统的IT管理和IT服务管理的比较如表2-1所示。

表2-1  传统IT管理与IT服务管理的对比

从组织层面上来看，IT服务管理将企业的IT部门从成本中心转化为服务中心和利润中心；从具体IT运营层面上来看，IT服务管理不是传统的以职能为中心的IT管理方式，而是以流程为中心。如图2-2所示，传统的IT管理是从各种IT基础设施出发，每种基础设施都由相关的维护人员对其进行管理。这种做法看似专业，但实际上存在非常大的问题，因为维护人员只是负责单个基础设施的维护，而IT系统出现故障，有可能涉及多个基础设施的问题，此时责任难以明晰，可能出现工作效率低下、相互推卸责任的现象。

图2-2  传统IT管理向IT服务管理的变迁

例如，希赛公司销售部吴经理无法登录OA系统，她找到负责OA系统维护的李工，李工对他说“你的OA系统账户状态是正常的，故障不是OA系统引起的，你应该找网络管理员王工，让他看看是不是网络出问题了”。于是，吴经理找到王工，王工经过检查，发现网络正常，告诉吴经理“目前公司网络运行正常，肯定不是我这方面的问题”。最终吴经理找到负责桌面电脑管理的系统管理员左工，左工发现吴经理的电脑中病毒了，有些系统文件遭到破坏，所以无法登录OA系统。

从上述简单案例可以看出，吴经理为了解决一个计算机系统故障，找了不少的人，最终才“幸运”的解决了问题，这种问题几乎每天都在各个组织中发生，它浪费了组织的大量资源，同时，也给员工带来了不好的感受。因此，这种传统的IT管理模式正面临淘汰。IT服务管理是从传统的IT管理活动中梳理出那些核心的流程，例如，事件管理、问题管理和配置管理等，将这些流程规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系。

对图2-2中的内容进行流程重新转化以后，得到的新体系如图2-3所示。例如，在上述例子中，吴经理无法登录OA系统，他只需到公司的IT服务台进行故障申报，接下来就只需冲一杯咖啡，等着IT管理部门的人员查清原因，帮他解决问题就行了。

图2-3  IT服务管理的结构

2.IT服务管理的内容

根据国际标准ISO/IEC 20000-1：2005的规定，IT服务管理主要包括服务交付过程、关系过程、解决过程、控制过程和发布过程等。

服务交付过程包括服务级别管理、服务报告、服务连续性和可用性管理、服务预算和核算、容量管理、信息安全管理等方面的内容。服务级别管理的目标是定义、协商、记录和管理服务级别；服务报告的目标是为做出基于知情的决策和有效沟通，编制商定的、及时的、可信赖的、准确的报告；服务连续性和可用性管理的目标是确保在所有条件下都能够达到承诺给客户的服务连续性和可用性；服务预算和核算的目标是提供服务成本的预算和核算；容量管理的目标是确保服务提供方一直具备充分的容量来满足当前和未来客户业务需求；信息安全管理的目标是有效管理所有服务活动的信息安全。

关系过程包括供应商管理和业务关系管理两个相关的方面。业务关系管理的目标是在理解客户及其业务驱动的基础上，在服务提供方与客户之间建立和维持良好的关系；供应商管理的目标是管理供应商，以确保提供无缝的、高质量的服务。

解决过程包括事件管理和问题管理，事件和问题虽然紧密相关，但它们却是独立的。事件管理的目标是尽可能快的恢复商定的提供给业务的服务或响应服务请求，问题管理的目标是通过对事件起因的主动识别和分析，以及管理问题的关闭（彻底解决该问题），以最大限度降低对业务的损害。

控制过程包括配置管理和变更管理。配置管理的目标是定义并控制服务和基础设施的组件，并维护准确的配置信息。一般来说，运维服务中配置管理是乙方（承建单位）的责任。应采用整合的方法，进行变更和配置管理的计划；变更管理的目标是确保以受控的方式评估、批准、实施和评审所有变更。

发布过程只包括发布管理，其目标是交付、分发和跟踪作为一个版本发布到运行环境的一个或多个变更。发布管理流程应与配置和变更管理过程相结合，发布管理过程应包括失败后的回退和补救方式。

3.服务管理的流程分析

从图2-3中可以看出，所有故障和请求都集中到服务台，服务台收到这些请求后，开始启动内部处理的流程。首先到达事件管理，此时客户提出的请求还不被定性为问题，而只是一个事件，如果该事件通过内部核查，找到了原因，并予以解决，则流程至此结束。但如果多次反复都找不到问题的原因，则将事件升级为问题，由问题管理部分进行深入研究，研究结果若涉及程序的修改（或缺陷的修正），则启动变更管理，遵循变更处理流程。修改结束后，转到发布管理，完成这次请求，并将新的服务支持反馈到事件管理。