it服务管理制度

it服务管理制度（精选6篇）

it服务管理制度 第1篇

IT服务管理制度 总则

1.1 为保障XX信息中心IT服务管理系统运维管理流程规范化执行，提高服务质量水平和用户满意度，特制定本办法。

1.2 本制度的适用范围为XX信息中心。事件管理

2.1 IT服务管理系统的事件包括用户的申告、故障、咨询，以及监控系统自动产生的告警。

2.2 事件处理过程中，如果需要对系统进行变更，必须提交变更请求单（变更单必须和事件单关联），变更完成后，继续事件单的处理。

2.3 事件处理过程中，若可以将故障定位到某个配置项，则必须将事件单与配置项关联。

2.4 由用户申报的事件，客服代表是该事件的责任人，必须确保事件得到有效跟踪与解决。

2.5 监控系统自动发送的事件单，由第一个接收的处理人员作为该工单负责人，负责过程跟踪和解决后的工单关闭。

2.6 服务台可以将事件单分配给一线工程师或二线工程师，一线与一线、二线与二线之间不能直接分派工单，一线可直接分派给二线，一线和二线可以将事件单重新分派给服务台。

2.7 重复事件必须被标识，如果服务台可以判断重复事件，则由服务台对重复事件进行标识，否则由事件处理人员负责重复事件的标识。

2.8 事件处理人员在完成解决事件后，应根据实际解决情况填写事件的结束代码，采用临时措施结束代码为“变通方法解决”。

2.9 服务台负责和用户确认事件的解决。由用户认可获得关闭的事件单的结束代码为“成功解决”；已解决的事件单如果没有得到用户的认可，须重新分配到原处理人员继续处理。

2.10 优先级为紧急的事件，服务台应立即分派给相应的工程师并电话通知，由工程师再次确认，确认为紧急事件，则应立即通报事件经理，事件经理协调资源处理。

2.11 各事件处理人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，系统自动将事件信息通报事件经理和服务台人员，事件经理负责协调资源，并督促事件能够及时被响应和处理。

2.12服务台应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理。

2.13 每周召开例会，总结经验，并进行趋势分析，主动发现潜在问题。2.14 每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，举行定期的事件管理会议对这些事件进行评估。问题管理

3.1 问题先由问题经理审核，再分派给相应的问题分析专家，问题分析专家负责问题的诊断与解决，问题经理负责与服务台或问题请求者沟通问题处理过程中的关键信息，已解决的问题单由问题经理关闭。

3.2 多次重复发生的事件在工作人员恢复服务后，应创建问题单（问题单必须和事件单建立关联）。

3.3 问题处理过程中，如果需要对系统进行变更，必须提交变更请求单（变更单必须和问题单关联），变更完成后，继续问题单的处理。

3.4 问题处理过程中，若可以将根本原因定位到某个配置项，则必须将问题单与配置项关联。

3.5定期组织会议，对所处理事件历史记录进行趋势分析，将发现的问题提交给问题经理。

3.6每月定期回顾和产生问题管理报表，对没有解决的问题，举行定期的问题管理会议进行评估。变更管理

4.1 所有影响生产环境配置项的变更均须填写变更请求单。

4.2 所有的变更必须通过变更经理审批，风险等级为重大的变更必须提前三个工作日提交变更经理审批。变更经理负责与各相关方面协同，严格管理其计划、测试、评估、审批、实施等。

4.3对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，变更主管均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告。

4.4变更主管负责变更计划的制订，包括：实施计划、测试计划、安全措施、回退计划、配置项更新计划等。

4.5在制定变更计划时需制定配置项更新计划并关联配置项信息，变更实施完成后需确保配置项信息及时更新，只有配置项更新完成后，才能关闭变更请求单；配置项信息的变更需要按照配置管理流程执行。

4.6对应用软件版本上线类的变更，除变更计划外，还应包括软件功能说明文档、软件技术说明文档、包含完整测试用例的测试文档，并提供已签字确认的测试报告。

4.7 对数据迁移类的变更，除变更计划外，还应提供转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容。

4.8每月产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查。配置管理

5.1 配置管理所有配置项信息必须准确反应当前IT基础架构状态信息，任何设备进入机房前或系统投入使用前必须启动配置管理流程，以确保配置项信息与实际环境一致。

5.2所有生产环境配置项的更改都要通过变更管理流程进行控制。只有得到授权的人员（配置管理员）才能对CMDB中的配置项信息进行修改。

5.3 变更主管在制定变更计划时必须制定配置项更新计划，对计划修改的配置项进行说明；变更实施完后，由变更主管汇总相应的配置项修改信息，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与配置项实体进行核

对，核对无误后方可修改配置项属性以及关系，同时将配置项与变更记录进行关联。

5.4 当确认配置项信息不需要在配置管理数据库CMDB中保留时，不在CMDB中进行物理删除，通过删除状态属性来进行标识。

5.5定期根据变更的执行情况对变更引发的配置项的修改情况进行审核。5.6每半年对IT环境进行审核、跟踪监测，以保证CMDB的信息收集准确、完整。知识库管理

6.1工作人员应积极支持知识库的建设，对于工作中的经验、知识、技巧、常见问题应及时总结，并提交给知识库经理。

6.2知识库经理须对工作人员提交的知识进行甄别，对于合格的知识才录入知识库。

6.3定期每个月对知识库中的知识进行整理和维护，保证知识的准确性和实时性。

it服务管理制度 第2篇

什么是IT服务管理，首先来看一个词：“ITSM”，这不是“IT系统管理（IT System Management）”的缩写，而是指“IT服务管理（IT Service Management）”。

伴随着微软、Sun、Borland公司的开发工具平台化战略，IT服务也已经成为IBM、HP的战略业务重点，二者都在着力拓展高端服务业务。

IT服务管理在国内算是一个新理念，它中引入了流程、标准的管理思想，以服务的理念来完成IT部门的技术支持工作。

图1：ITSM服务管理系统逻辑结构

IT部门作为一个技术支持部门，常常扮演着救火队的角色。但是由于其工作的特殊性，也有人把IT部门的工作形容为“打游击”。

对于企业中的IT部门，缺乏衡量其投资与汇报的方法，无法体现其价值，得不到认可。曾经有企业IT部门的人这样描述说：自己在沿海地区一大型企业从事IT部门管理工作，平日里杂事很多，但是作为非核心部门，地位不高。当然，IT部门的工作本身存在不少的缺陷，其中重最要的一点在于其活动是打游击性质的，体现出来就表现为对IT部门的工作本身缺乏管理。

在IT服务管理的核心中，强调IT部门应该转变思想，不要总把自己当作“丫环”，而是把其对企业的技术支撑作为一种服务来提供，并且以流程的思想来实现对其自身服务的管理，继而将服务标准化，形成一种产品。这里非常强调“流程”的思想，即建立一套规章制度来实施对服务的有序化管理。

二、ITSM的标准：ITIL

“流程化”的IT服务管理必须具有自己的即标准，以来衡量服务质量。ITSM自己的“行为准则”，即ITIL（IT Infrastructure Library，IT基础架构库）。

早在1980年代,ITIL已经在西方国家的IT服务管理的最佳实践中得到萌芽。到，成为英国标准协会的IT服务管理标准，即BS15000。到了5月17日，更是快速通过成为ISO国际标准，即ISO0。ITIL已经被国际社会广泛接受。ITIL结合流程、人员和技术三要素，为企业的IT建设提供一套从计划、研发、实施到运行维护的最佳实践方案。

图2：ITSM闭环管理模型

ITIL最早是被引入中国的。在被引入后的前3年，由于人们对它的了解并不多，这方面的成功案例也相当有限，所以在国内处于一种不愠不火的状态。但是从开始，ITIL在国内开始受到越来越多的关注。

三、 ITSM面临的问题和挑战

IT服务管理作为相对而言的一种新理念，在应用和实践中也面临着一些问题和挑战。

所面临的问题，主要包括需求变化性、复杂性、成本管理、安全性等。

 •变化：IT业务需求变化快、IT工作负荷大、IT服务能力服务水平有局限性；

 •复杂性：各种各样的IT资源、大量基础设施和复合应用程序；

 •成本：管理和监管，要求不断提高投资回报率；

 •安全性：规章、安全性和审计能力；

而IT服务管理面临的挑战，主要有：

1、IT资产管理的挑战

 •设备和软件供应商众多，厂商范围和时间跨度都很大，信用和评价目前还停留在人工管理的范畴，需要用IT技术手段管理。

 •设备的定期排查力度不够，设备巡检不到位。

 •设备台帐不能方便反映设备维修历史记录。软件资产未建立台帐进行管理，软件的升级、变更等缺乏登记信息。

 •设备和软件的配置信息不详，或者配置信息经过长期维修调整已经与实际不相符合，

 •设备采购、调拨、报废等管理流程未实现联网审批处理，效率低。

2、合同管理的挑战

 •目前停留在合同文本存档保管层面，需要进一步提升到监督合同的执行和检查合同执行效果的这一个层面；对合同的乙方不能形成比较客观的评价。

 •设备维修保养合同缺乏有效的管理，表现为出了问题或故障才通知相关维保厂商，而不是跟踪执行合同，提前解决更新换代问题，采取预防措施。

3、运维管理的挑战

 •维护的系统众多，凸现人员的配置不足。

 •故障处理过程缺乏共享的记录信息和跟踪信息；故障处理流程没有实现自动化。

 •维保厂商或外包服务商处理故障缺乏电脑化记录，服务进度无法在线监控，服务质量缺乏考核手段。

 •遇到突发情况，没有快速的汇报机制，不能快速解决问题。

 •没有形成有效的知识库，遇到相同的问题，不能从知识库获取解决问题的办法，还是要依赖个别维护人员。

 •月度年度运维分析报告编制困难，PC、ATM等设备故障量故障类别的变化趋势无法分析。开机率、维护成功率 、维护及时率等指标缺乏统计工具。

4、绩效管理的挑战

 •需要功能比较强的IT服务工作量量化考核工具，计算IT服务人员的工作绩效。

 •领导层面需要方便督办服务工程师解决故障，需要统计工作量、分析处理效率和处理质量。

 •服务工程师解决问题时缺乏协作，责任不清晰，经常扯皮。

 •外包服务商或厂家工程师处理及时率缺乏准确统计数据。

IT基础建设上台阶之后，越来越多的客户想到“向管理要效益”，向IT投资要回报，并且把客服优势作为其核心竞争力。体现在市场上，就是对IT服务管理需求的快速增长。

四、 IT服务管理的解决与实施

今天，ITSM( IT Services Management)发展到IT运维的业务驱动阶段，即用户开始实行IT资源的动态分配，向管理要效益。其特点在于制定服务目录，引进财务管理，乃至于让业务部门按服务的级别和内容向IT部门（IT服务商）付费，以减少资源浪费，提高生产效率。

简而言之，ITSM也可以划分为两个时期，第一阶段是以网管软件为标志的自动化时代，第二阶段是以流程解决方案为核心的流程管理时代。前者不需要人的参与，而后者必需要有人来参与；前者是对IT基础设施的管理，而后者从本质上说是对人的管理,也就是我们常常说到的”管理以人为本”。

由此可见，IT服务管理是从业务入手，用软件工具来调配IT资源，解决客户所遇到的业务问题。

基于企业实践考量, 我们才能够提炼出关注客户的重点诉求和需求的面向服务流程的解决方案:

1.集中的IT资产管理数据库（硬件和软件）；

2.开放的、基于WFMC标准的流程管理系统；

3.自动化的、按ITIL基础架构排列的管理工具和流程管理程；

4.一个开放性的基于.Net平台的伙伴开发系统。

部署企业ITSM软件系统，由顾问团队协助进行客户化应用实施，并导入ITIL管理方法，使ITSM软件系统成为专业的IT服务提供商或者企业内部IT部门的“ERP” ，从而提升企业内部IT服务能力，提高专业IT服务商的服务效率和市场竞争力。

基于ITIL架构理论开展咨询实施项目，提供IT服务管理系统，部署IT运营管理层面的软件模块，包括服务台、事件管理、问题管理、配置管理等重点管理模块，并部署流程管理平台软件和IT资产管理软件。

在实施过程中，要注意一下几点：

 •按照ITIL理念和实际需要理顺服务流程 ；

 •培训、变更、推进；

 •结合绩效考核等管理手段；

 •使用工作流平台管理软件系统作为服务支撑工具；

it服务管理制度 第3篇

随着移动互联网、物联网、大数据时代的到来,云计算业务迅猛发展,企业的业务数据越来越集中,这就要求IT组织(不管它是企业内部的还是外部的)提供更加安全、可靠的服务,并在提升服务质量的同时,降低维护成本。

为此,IT组织应以服务的生命周期为主线,按需设计服务,并确保服务设计与组织内的各职能单元无缝集成。建立以流程为核心的服务管理体系,在职能构架上实行流程式管理,提供专业化、标准化、规范化的服务。通过IT服务管理平台的建设,规范服务支撑各关键流程的运作,提高服务运营的可视化,为服务质量改进和成本控制提供依据。

2 建设基于ITIL的服务管理体系

IT服务管理的核心思想是,IT组织的主要工作就是提供低成本、高质量的IT服务。而IT服务的质量和成本则需从(购买IT服务的)客户和(使用IT服务的)用户方加以判断。IT组织实施IT服务管理的根本目标有三个:(1)以客户为中心提供IT服务;(2)提供高质量、低成本的服务;(3)提供的服务是可准确计价的。

2.1 ITIL

ITIL提供了IT组织实施IT服务管理的框架指南,涉及流程、功能定义及组织机构等。IT组织通过ITIL的实践,优化业务流程、提高效率,提高IT服务价值和用户满意度。

ITIL生命周期模型由面向流程的ITIL V2发展而来,定义了服务战略、服务设计、服务转换、服务运营和服务改进五个模块。其对应的主要流程模块如图1所示。

2.2 BISL、ASL与ITIL

ITIL定义了IT基础设施的运营管理的框架,BISL(业务信息系统管理库)和ASL(应用服务库)则定义了IT业务管理和应用管理的框架。

图1 ITIL流程模型

IT组织需将三者有机结合起来,才能定义完整的IT服务管理体系,三种框架的结合见图2。

图2 IT服务管理的三种框架

2.3 IT服务管理体系建设

IT组织以IT服务管理的三种框架为依据,根据服务价值链模型进行IT服务管理体系规划,主要包括六方面的内容:

(1)分析业务市场,明确服务需求,确定服务规模、范围及服务等级。

在进行竞争对手及监管策略的分析后,确定细分市场及目标市场。通过业务梳理,明确组织的业务目标,并进行IT服务规划。

(2)根据产品及业务策略,进行能力和资源的分析,制定成本收益目标及服务质量目标。进行服务能力体系的建设,明确服务级别管理要求,从而制定服务监控及服务支持要求,并建立服务运营流程。

(3)建立统一受理平台,受理用户服务请求。

(4)针对不同客户,进行服务支撑方案设计,明确服务运营流程。其中,基本的服务运营流程包括:

●IT服务过程管理:服务受理、故障管理、问题管理、变更管理、发布管理、配置管理、服务级别管理及安全管理等;

●IT服务资源管理:服务级别管理、知识管理、供应商管理、备品备件管理等;

●日常运行维护体系:服务监控、日常支撑操作等。

(5)建立通用技术保障体系,为服务提供技术保障。

(6)建立服务评价机制,并持续进行服务改进。

IT服务管理体系架构见图3。

图3 IT服务管理体系架构

3 IT服务管理平台

3.1 平台规划

IT组织在建立IT服务管理框架后,基于人工方式及纸质表单运行的IT服务管理体系,各个流程之间数据无法共享,导致流程效率低下,不利于业务的规模增长,且管理人员无法从现有的业务数据中提供有效的支撑用于业务决策(图4a),要求IT组织通过IT服务管理平台建设及应用,规范IT服务管理流程及数据,确保服务数据在各个流程中的共享,从而提高IT运营效率和服务质量(图4b)。

图4 IT服务管理平台实施前后数据流图

IT服务管理系统作为IT服务过程的管理工具,其建设目的是依据IT组织的服务管理体系要求,对服务交付过程进行管理,从而实现组织的IT服务目标。这些交付过程包括:日常运行维护管理、IT运营管理过程、服务过程的记录、测量、监督和评估等。根据IT服务管理框架,进行服务支撑流程、服务支撑组织、服务管理对象的梳理,明确各流程之间的关系、界面,并对服务支撑各环节产生的信息进行分析规范,规划IT服务管理平台的基本架构(如图5所示)。

●用户界面层:是用户访问平台的界面,可根据不同用户的权限及应用访问需求展示不同的用户视图;

●应用层:应用层实现统一接入、一点受理的功能。实现基于服务级别管理的事件管理、故障管理、问题管理、变更发布管理、资产配置管理等服务管理过程的管理。

●基础架构层:为应用层提供基本的数据管理、工作流引擎及基础配置信息管理,并提供API(应用程序编程接口)。

图5 IT服务管理系统架构图

●接口层:实现与监控系统、自动巡检系统及其他第三方系统的接口。

3.2 系统实现

(1)平台基本技术要求

IT服务管理平台在实现和部署方面,应该满足以下几个方面的基本技术要求:

●能够对包括网络系统、主机系统、存储/备份系统、应用系统、终端系统、安全系统、机房动力及环境等资源进行集中统一管理。

●系统结构清晰,能够采用层次化、模块化的设计理念,各功能模块功能独立、松耦合,而系统整体功能完备,便于客户根据需求自由组合。

●系统应具有较强的开放性和扩展性,通过插件体系和数据交换接口,可平滑地扩展系统功能并与第三方产品进行集成。

●能支持各类通用的硬件和操作系统平台。

●可对管理信息进行综合展现,可以根据用户需求定制个性化业务窗口,可支持定制化二次开发。

●满足系统使用过程中容量和效率的要求。

(2)平台开发框架

依据IT服务管理平台,确定平台开发框架采用JAVA技术,与主流平台及数据库兼容。基于模块化架构开发,通过应用API接口实现应用层对数据层的访问,具有良好的可伸缩性和可扩展性,并可根据客户需求进行快速业务部署,满足产品化需要。

系统在软件架构分为五层(见图6)。

图6 系统技术架构图

第一层为展示层,负责处理与用户的交互;

第二层为控制层,负责接收和处理展示层的数据;

第三层为业务层,负责处理系统功能业务逻辑,该层根据功能业务需要,与流程引擎、计划任务调度引擎进行交互;

第四层为缓存层,负责与缓存系统交互;

第五层为数据层,负责与数据库系统交互。

软件架构采用面向对象的设计方式进行整体设计,将业界经典的设计模式引入其中,通过细粒度的分层构架,每层各负其职,互不干扰,达到松耦合的设计目的,将系统功能的变更影响降到最低,使系统更易扩展、更易维护。

(3)流程引擎技术

采用自主研发的流程引擎组件,安全、稳定、灵活、可靠,具备二次开发能力。

●界面友好的可视化流程设计界面,支持拖拽操作;

●支持丰富的流程语义及节点类型;

●支持基于规则引擎的路径选择功能;

●工作流引擎采用先进的核心架构设计,支持分布式部署方式,支持水平扩展,可提供高可用、高性能的服务。

(4)接口管理

基于SOA(面向服务的体系架构)实现,系统中的每个最小执行单元都可以以服务的方式对外提供访问能力;系统提供丰富的对外接口协议,包括:webservice、socket、Restful API、基于数据库级的接口(DBLink、接口表)等,通过这些常用、标准的协议可以方便地与外系统进行数据交换。数据交换格式支持结构化文本(csv、json、xml)等。

4 IT服务管理平台在IT服务管理中的应用分析

笔者所在公司作为电信级的IT外包服务提供商,基于ITIL、ISO 20000、ISO 27001、ASL、BISL等国际标准体系,建立了成熟的IT服务体系,覆盖服务响应、服务交付和服务管控的全过程。在此基础上,依据自身业务特点及服务能力,建设应用IT服务管理系统,实现了电子化的服务流程定义、服务协议管理及服务监督管理等。

通过服务及运维管理过程的电子化闭环管理,实现生产运营的可控性。

该平台实现对服务支撑情况的可视化分析,帮助管理人员进行服务成本分析及服务质量考核,从而进行服务质量和流程的优化改善。

该平台依据主流的IT服务标准建设,具有良好的可伸缩性和可扩展性,可根据客户需求进行快速业务部署,具有良好的市场推广价值。

该平台已在联通集团、联通黑龙江分公司等ITO项目中部署使用,提高了服务及运维管理水平和效率并降低运维成本,提高了客户服务质量及满意度。

参考文献

[1]波恩(荷).IT服务管理国际标准体系[M].北京:清华大学出版社.2009.

[2]Mauricio Salatino.j BPM6 Developer Guide[M].UK:Packt Publishing Limited,2014.

[3]高杰.深入浅出j BPM[M].北京:人民邮电出版社,2009

[4]Frank Niessink,Hans van Vliet.Vrije大学IT服务能力成熟度模型[C/OL].荷兰阿姆斯特丹:Vrije大学.1999.(2015-03-17)[2016-08-24].http://doc.mbalib.com/view/a9b4dfaa25f2f56e40ca46af8666d5bf.html.

IT服务项目管理实践 第4篇

关键词 IT服务 项目管理 责任和挑战

中图分类号： TP393 文献标识码：A

1 IT服务管理的重要性

1.1 业务的快速变化对IT部门提出了更高的要求

面对全新的业务环境，IT部门将面临多方面的压力与挑战：

（1）当业务需求更快速的变化时，如何能更快速响应业务、及时推出新IT系统？

（2）当面临更多法律法规的管控要求时，如何保证IT系统合规、安全、稳定的运行？

（3）当业务对信息技术依赖性逐渐增强时，如何实时掌握系统运行质量？

（4）当用户愈加成熟从而提升服务质量意识时，如何提升服务效率和服务质量？

1.2 IT服务管理项目组织特点

（1）广泛参与度。IT服务管理项目经理首先要明确的一点是面向业务的，与所在企业及企业所处商业环境密不可分，所以IT服务管理的推行应当秉承着作为企业资产有机组成部分原则去做。另外一点需要清晰认识到，IT服务管理不能一蹴而就，而是长期的、阶段性的、持续推进的事情，通常需要3到5年的持续改进。

IT服务管理项目咨询方的参与是很必要的，主要有以下原因：

提供专业方法论；

提供行业经验；

帮助决策；

协助推动项目；

实施指导和支持。

（2）矩阵式管理。矩阵式管理将组织按两个或两个以上维度划分，比如按照职能和流程角色。矩阵式管理的应用方式简单来说就是资源调配，需要资源了就按照某个维度去调配，用完了再还回去。

IT服务管理项目组就是个典型的矩阵式管理组织，项目团队中的成员来自不同的部门，有他们所在职能的工作还要承担项目中的相应角色并承担一定的义务，这样多种角色多头汇报的情形在项目推进过程中就难免发生“扯皮”现象了。这样本来想要提高效率的管理方式却可能导致管理成本、沟通成本增加的结果。

（3）项目组织结构。

将流程Owner角色的部门领导放在推行组，并作为项目任务的监督者，这样对增强沟通及减少“扯皮”现象会有所帮助。

1.3 考核与激励

与好的工作效果相关的三个方面：自己喜欢当前的工作，领导分配的任务不得不完成，任务会被考核并与自身绩效挂钩。项目组织结构中可以完成前两步，而在绩效与激励方面先要同老板沟通，提供2～3个适合所在企业的方案得到认同后再与人力资源讨论、落实。

1.4 动态交互性

IT服务管理项目团队的组成是甲、乙双方共同参与，双方通过高度互动共同完成知识转移和渗透，主要形式包括：

培训，管理体系培训、IT服务管理流程培训、流程设计培训、工具应用培训、实践培训等；

访谈，现状调研阶段、阶段性实施后成果访谈等；

讨论，报告、例会、临时会议、咨询等；

宣传，共同制作内刊、宣传材料、问题、内部培训等；

内审，从项目启动后就应当开始建立这种自发的改进制度。

这个互动过程起初会借助乙方的经验来运行，甲方要主动参与和学习慢慢的将经验知识转移为自己的工作内容，有明显效果的应当定位制度固化下来比如内训，比如内审。

1.5 长期性

IT服务管理项目不是交钥匙工程，不是贴标签工程，更不是可以一蹴而就的，它是对工作习惯和管理方式的改变。虽然有ITIL有Cobit等最佳实践，但还是需要根据自身业务特点因地制宜、循序渐进、稳扎稳打的落实，依据项目范围及企业规模不同可能需要3～5年甚至更长的时间进行持续改进最终与业务融合。

2 IT服务管理项目责任和挑战

2.1 主要职责

（1）炼材：选人、沟通、激励是主旋律，锻炼队伍、培养人才是目的。

企业推行IT服务管理项目，主要是解决实际中现存的问题然后是效益，但无论前后都涉及到业务领导、部门负责人、职能承担者等，那么依照IT服务管理项目解决哪方面问题、实现哪方面效益不同项目经理应当选取不同的人来参与，包括企业内部、咨询公司、厂商的人员的选取。

（2）成事。

做成一件事情涉及到多方面，企业文化、计划、组织等，说到底识别并规避风险，然而是不是可以将与IT服务管理项目相关的风险都识别出来，识别出来的是否都能解决？行业相异、企业不同、具体情况更是千差万别，这里仅说一些常见的风险。

组织架构变动，一方面人员职责不明确，另一方面人心浮躁，这两点都足以阻碍项目的推进；最好的规避措施就是等待组织架构变动完成后再推进项目，如果在项目进行中组织架构变动，为组织架构变动预留足够的时间是个明智的做法。

过度依赖咨询公司。咨询公司可以带来体系化的知识与客观的建议，可以比喻为甲方的“拐杖”，无论是对业务的理解、IT服务管理落地还是长久的应用，甲方都是主角。规避措施可以使以下几种：

拥有对企业业务有深刻理解并有丰富IT服务管理经验的帶头人；

建立一只甲方自己的IT服务管理队伍，结构上分成三个方面：包括具备IT服务管理意识的业务端、对业务端支持的IT服务管理团队以及质量体系监控方；

领导的高度重视；

熟悉企业业务的咨询公司；

明确的阶段性目标，切实可行的项目计划、WBS，以及被认同的预算。

2.2 关键技能

（1） 领导能力。

由于IT服务管理项目结构的特点，项目成员有业务或技术高层担任的管理者代表、其他部门的经理或员工。在这种情况下采取参与式或顾问式的的领导方式会比独裁式或命令式的更为有效，实际上在平衡利益、争取意见一致性方面的阻力也会较小，明确了领导方向也就给项目成功定下了一个基础。

有了适合的领导方式，就需要团结各方力量协同工作，关键在于建立“信任”。可以從以下几方面去考虑：

律己：言行一致，如果要求别人加班或者细致的工作，要让自己先做榜样；

用人不疑：授权相对于职能不要反差太大，一旦明确授权就要充分信任，建立起战友般的友情与忠诚；

正向引导：使团队成员充分了解项目结果和利益，通过生动描绘目标达成的结果使大家了解实现项目的收益。

（2）沟通能力。

IT服务管理项目经理必须是一个良好的沟通者，他要与项目团队成员、各相关部门、咨询公司、产品厂商等进行定期的沟通。只有通过有效的沟通，才能确切了解各方面实际的情况，发现潜在问题，制定解决方案，协调关系、集结资源使项目向着期望的方向前进。

（3）人际交往能力。

良好的人际交往能力可以影响周围人的思想及行为，在项目推进中IT服务管理项目经理会与项目团队成员或者高层管理者进行说服和协商工作，比如出于公司整体考虑，需要利益平衡将改进的进度延后。

（4） 时间管理能力。

良好的时间管理能力可以说是项目成功的一个必要条件，列出一些常见的时间管理技巧；

优先计划管理：按重要程度和紧急程度来确定先做什么后做什么，如：重要紧急的优先分配时间完成，重要不紧急的每天都持续一段时间做，不重要但紧急可以安排给别人做，不重要不紧急的最好不占用团队时间；

适用时间计划工具，编制计划并进行跟踪，有时候一个CheckList效果也不错；

把工作授权给他人：不必每一项工作都事必躬亲，授权给部下一样干的好而且还能锻炼队伍；

拥有良好的心态：压力并非来自已经解决的事情，而是来自未能克服的困难。

2.3 面临的主要挑战

（1） 组织结构与项目范围的变化。

IT服务管理项目不一定都会遇到组织结构与项目范围的变化，但如果你碰到了，可以肯定的是有很多事情都要变，包括指定的计划、铺垫的关系以及和领导预先的沟通甚至承诺。坦然面对这些，这种事情并非无法克服。无论如何，这种变化通常是高层管理者在变革过程中平衡公司内部各种利益的方式，从长远来看对IT服务管理项目执行和贯彻是有好处的。

（2）跨部门协调与沟通。

无论是对内提供服务的内部IT还是对外提供服务的IT服务供应商，在做IT服务管理项目的时候都会涉及到跨部门的协调与沟通。而IT服务管理主要是针对管理精准化、规范化的一种项目，推行过程中一旦涉及到利益的平衡就会有得失，相应的跨部门的沟通就会遇到阻碍。

措施：与管理者代表沟通，制定规则；定义每周例会，相关部门的流程经理都要参与，必要时也可以邀请职能经理参与；会议中可以将跨部门协调、沟通有难度的拿出来讨论，并记录会议纪要，会后将会议纪要分发至相关人员。

2.4 IT服务管理项目实施中沟通问题

IT服务管理应用场景很多，有的是运维环境、有的是呼叫中心、有的是BPO形式的对外服务，项目团队中会有技术专家、业务专家、管理专家，这样沟通的时候就会有问题。

通常技术专家在谈论的时候会用到联通性、延时、流量、丢包率、MTU描述网络性能，用DAS、NAS、SAN来告诉别人我们的存储是怎样的，或者开个玩笑“写SQL，Delete的时候竟然忘了用where”，在笑的前仰后合的时候很难说另外两组专家有何想法。

业务专家很清楚IT服务是什么，他会说我关心的是服务产品化，可以持续的快速复制，让我们在竞争环境中处于有力地位提升市场占有率，还要控制成本；当然毛利率高了他们才有收益，了解业务的技术专家会这么想。

管理专家两方面都会了解一些，而且说明问题的时候总能深入浅出“瞧，CMDB是个逻辑库，你可以把AIX想成一个装满白菜、萝卜的大柜子，而我们只要有个列表……”不过，这可能让系统管理员表情显得不自然。

这些日常的话语并非问题或者冲突本身，只是借用的一种方式，这说明我们可能忽略了一些本该有的沟通，有时是内部的、有时是外部的。

参考文献

[1] 杨坤，王玉.IT项目管理[M].北京：机械工业出版社，2008.

[2] 欧立雄，成功的项目管理[M].北京：机械工业出版社，2008.

浅谈IT服务管理 第5篇

什么是IT服务管理，首先来看一个词：“ITSM”，这不是“IT系统管理(IT System Management)”的缩写，而是指“IT服务管理(IT Service Management)”。

伴随着微软、Sun、Borland公司的开发工具平台化战略，IT服务也已经成为IBM、HP的战略业务重点，二者都在着力拓展高端服务业务。

IT服务管理在国内算是一个新理念，它中引入了流程、标准的管理思想，以服务的理念来完成IT部门的技术支持工作。

图1：ITSM服务管理系统逻辑结构

IT部门作为一个技术支持部门，常常扮演着救火队的角色。但是由于其工作的特殊性，也有人把IT部门的工作形容为“打游击”。

对于企业中的IT部门，缺乏衡量其投资与汇报的方法，无法体现其价值，得不到认可。曾经有企业IT部门的人这样描述说：自己在沿海地区一大型企业从事IT部门管理工作，平日里杂事很多，但是作为非核心部门，地位不高。当然，IT部门的工作本身存在不少的缺陷，其中重最要的一点在于其活动是打游击性质的，体现出来就表现为对IT部门的工作本身缺乏管理。

在IT服务管理的核心中，强调IT部门应该转变思想，不要总把自己当作“丫环”，而是把其对企业的技术支撑作为一种服务来提供，并且以流程的思想来实现对其自身服务的管理，继而将服务标准化，形成一种产品。这里非常强调“流程”的思想，即建立一套规章制度来实施对服务的有序化管理。

二、ITSM的标准：ITIL

“流程化”的IT服务管理必须具有自己的即标准，以来衡量服务质量。ITSM自己的“行为准则”，即ITIL(IT Infrastructure Library，IT基础架构库)。

早在1980年代,ITIL已经在西方国家的IT服务管理的最佳实践中得到萌芽。到，成为英国标准协会的IT服务管理标准，即BS15000。到了5月17日，更是快速通过成为ISO国际标准，即ISO0。ITIL已经被国际社会广泛接受。ITIL结合流程、人员和技术三要素，为企业的IT建设提供一套从计划、研发、实施到运行维护的最佳实践方案。

图2：ITSM闭环管理模型

ITIL最早是被引入中国的。在被引入后的前3年，由于人们对它的了解并不多，这方面的成功案例也相当有限，所以在国内处于一种不愠不火的状态。但是从开始，ITIL在国内开始受到越来越多的关注。

三、 ITSM面临的问题和挑战

IT服务管理作为相对而言的一种新理念，在应用和实践中也面临着一些问题和挑战。

所面临的问题，主要包括需求变化性、复杂性、成本管理、安全性等。

 •变化：IT业务需求变化快、IT工作负荷大、IT服务能力服务水平有局限性;

 •复杂性：各种各样的IT资源、大量基础设施和复合应用程序;

 •成本：管理和监管，要求不断提高投资回报率;

 •安全性：规章、安全性和审计能力;

而IT服务管理面临的挑战，主要有：

1、IT资产管理的挑战

 •设备和软件供应商众多，厂商范围和时间跨度都很大，信用和评价目前还停留在人工管理的范畴，需要用IT技术手段管理。

 •设备的定期排查力度不够，设备巡检不到位。

 •设备台帐不能方便反映设备维修历史记录。软件资产未建立台帐进行管理，软件的升级、变更等缺乏登记信息。

 •设备和软件的配置信息不详，或者配置信息经过长期维修调整已经与实际不相符合，

 •设备采购、调拨、报废等管理流程未实现联网审批处理，效率低。

2、合同管理的挑战

 •目前停留在合同文本存档保管层面，需要进一步提升到监督合同的执行和检查合同执行效果的这一个层面;对合同的乙方不能形成比较客观的评价。

 •设备维修保养合同缺乏有效的管理，表现为出了问题或故障才通知相关维保厂商，而不是跟踪执行合同，提前解决更新换代问题，采取预防措施。

3、运维管理的挑战

 •维护的系统众多，凸现人员的配置不足。

 •故障处理过程缺乏共享的记录信息和跟踪信息;故障处理流程没有实现自动化。

 •维保厂商或外包服务商处理故障缺乏电脑化记录，服务进度无法在线监控，服务质量缺乏考核手段。

 •遇到突发情况，没有快速的汇报机制，不能快速解决问题。

 •没有形成有效的知识库，遇到相同的问题，不能从知识库获取解决问题的办法，还是要依赖个别维护人员。

 •月度年度运维分析报告编制困难，PC、ATM等设备故障量故障类别的变化趋势无法分析。开机率、维护成功率 、维护及时率等指标缺乏统计工具。

4、绩效管理的挑战

 •需要功能比较强的IT服务工作量量化考核工具，计算IT服务人员的工作绩效。

 •领导层面需要方便督办服务工程师解决故障，需要统计工作量、分析处理效率和处理质量。

 •服务工程师解决问题时缺乏协作，责任不清晰，经常扯皮。

 •外包服务商或厂家工程师处理及时率缺乏准确统计数据。

IT基础建设上台阶之后，越来越多的客户想到“向管理要效益”，向IT投资要回报，并且把客服优势作为其核心竞争力。体现在市场上，就是对IT服务管理需求的快速增长。

四、 IT服务管理的解决与实施

今天，ITSM( IT Services Management)发展到IT运维的业务驱动阶段，即用户开始实行IT资源的动态分配，向管理要效益。其特点在于制定服务目录，引进财务管理，乃至于让业务部门按服务的级别和内容向IT部门(IT服务商)付费，以减少资源浪费，提高生产效率。

简而言之，ITSM也可以划分为两个时期，第一阶段是以网管软件为标志的自动化时代，第二阶段是以流程解决方案为核心的流程管理时代。前者不需要人的参与，而后者必需要有人来参与;前者是对IT基础设施的管理，而后者从本质上说是对人的管理,也就是我们常常说到的”管理以人为本”。

由此可见，IT服务管理是从业务入手，用软件工具来调配IT资源，解决客户所遇到的业务问题。

基于企业实践考量, 我们才能够提炼出关注客户的重点诉求和需求的面向服务流程的解决方案:

1.集中的IT资产管理数据库(硬件和软件);

2.开放的、基于WFMC标准的流程管理系统;

3.自动化的、按ITIL基础架构排列的管理工具和流程管理程;

4.一个开放性的基于.Net平台的伙伴开发系统。

部署企业ITSM软件系统，由顾问团队协助进行客户化应用实施，并导入ITIL管理方法，使ITSM软件系统成为专业的IT服务提供商或者企业内部IT部门的“ERP” ，从而提升企业内部IT服务能力，提高专业IT服务商的服务效率和市场竞争力。

基于ITIL架构理论开展咨询实施项目，提供IT服务管理系统，部署IT运营管理层面的软件模块，包括服务台、事件管理、问题管理、配置管理等重点管理模块，并部署流程管理平台软件和IT资产管理软件。

在实施过程中，要注意一下几点：

 •按照ITIL理念和实际需要理顺服务流程 ;

 •培训、变更、推进;

 •结合绩效考核等管理手段;

 •使用工作流平台管理软件系统作为服务支撑工具;

IT服务管理五个心得 第6篇

其实，实现IT服务管理，并不难。

夏忙，28岁，2004年4月进入滚滚来贸易公司，负责IT工作。滚滚来贸易公司以做进出口为主，这几年发展尤其快，从最初的几十人到了现在的200多人，而且基本上是人手一台PC。网络、邮件已经逐步替代了以前的电话、传真，成为最新的办公手段。

IT部门有三个人，夏忙一来就发现这三个人基本都不在自己的座位上，因为公司的200多台机器，总有这样、那样的问题报过来。于是，夏忙也就很快投入了战斗一线，修机器、调邮件、杀病毒，成了被拎来拎去的“八抓鱼”。

忙归忙，可是每到月底填写考核表的时候，夏忙就一点都想不起来这个月干了什么。好像每天都没闲着，也好像每天都当救火队员，但是看看这个月有什么进步？除了扑了几次一样的火，修了几次机器以后，再也没有什么可以书写的记录了。

最让他郁闷和委屈的是，累死累活一个月下来，虽然忙得手脚不着地，可挨领导的批评也更多了，因为虽然问题是解决了，却收到了更多的投诉：找不到人、反应速度太慢、相似的问题总出现、没有预防措施„„

总之，每天早晨，夏忙最担心一件事，今天会不会发生灾难性事件；每个月底，夏忙担心另外一件事，这个月因为遭遇投诉工资被扣了多少钱。

1一站式服务少干活多挣钱

2004年8月31号，工资发下来之后，夏忙发现被扣了很多钱，IT部门的其他同事也是一样。后来才知道，主要原因是他帮大家修机器时不在座位，别人有事打电话总找不到人，自然提意见。

从加盟滚滚来公司到现在已有半年时间，夏忙越来越忙，因为单位人员在不断增加，系统越上越多，加上最近病毒等“天灾”频频光临公司，事情也越来越多。时下IT部门只有3个人，人手实在是太少了，有时候大家一起打电话求助，夏忙苦于应付，遇到不该自己管的事情，夏忙就总是告诉打电话者该找小欧，放不下手里活的小欧只好说，你找小王，结果是被集体投诉推托责任。

夏忙也有委屈，一个人分身乏术，人家业务部门的人一打电话来肯定得冲到一线，三个人都放出去，一旦活够复杂，电话没人接也就成了常有的事。

从8月中旬开始，夏忙陆续接触了IT服务管理的“一站式”服务概念。所谓“一站式”服务，就是业务部门可以一次性获取IT热线、IT现场等各种形式的IT服务，解决所有日常办公IT问题。“一站式”服务的精髓是IT服务台。IT服务台是用户与IT服务部门的中心联络点，客户的IT问题通过IT服务台获取答案和帮助。对于夏忙，通常来说，IT服务台可以有两种表现形式，一是电话申请服务，当用户的系统出现问题时，可以拨打服务台电话，根据语音提示选择不同的问题类别；二是网络申请服务。在IT网络服务中，夏忙建立了一个简单的基于Web形式统一入口，业务部门可通过Web的形式提出问题，问题自动提交到相应的IT工程师并进行解答,工程师之间也可以互相转移。作为一种很好的互动式服务渠道，是电话服务的补充。

建立IT服务台之后，夏忙他们三个人针对分工不同，排除了接了电话乱找人的情况，并定义了首问负责制：哪位工程师最先接到业务部门的电话，就成为该CASE的责任人，他需要自己或者协调相关人员解决并关闭这个“CASE”。这也解决了工程师间互相推委的现象。

服务台建立起来后，并非万事大吉。大家还是觉得电话方便，随叫随到。夏忙只好向老板申请，把IT部门新的服务方式形成制度，大家来学习和维护。

机器加人工，基本上满足了同事们的救援需求。

小贴士：

问题响应方式固然重要，但让大家知道并且习惯也是一个过程。对于IT人员来说，要公示响应方式，让业务部门能够主动使用、愿意使用并满意使用。

建立了服务台管理之后，夏忙从八爪鱼变成了随需应变的百变神形。因为响应及时，夏忙最近没听见什么抱怨。

一天，电脑提示收到一封事件警报邮件，同时，另外三封事件报警邮件也发到了夏忙的信箱。桌上的电话刺耳地响起，另外两位同事的电话声此起彼伏。

销售部的同事反映无法接收邮件。夏忙刚刚扑到销售部查问题，不多久，人事那边也找夏忙，人事部的PC系统崩溃了，夏忙指挥同事去人事部处理这一问题。事情还在处理中，忽然又接到一个报警，说财务的机器上不了网，现在是月底要报税，事情紧急。于是IT部门最后一个人去了财务部。夏忙忙乱得一头大汗，他不知道假如再来一桩突发事件，他该怎么办。此时，一直有人在找夏忙，有的机器中毒，有的机器蓝屏了等等。夏忙只好不停地说，“稍等——，稍等——”，一位急脾气的同事不耐烦了，“我急着要一份数据，硬盘却坏了，能不能先给我看看？”

“手边有紧急的事没处理完呢。”

“那你得分个轻重缓急啊。”夏忙一听，觉得有理，层出不穷的技术故障让IT部门的人疲于奔命，成了“救火队”。可状态不能老这么持续下去，需要有一套流程和方法来有序地处理。他决定把手边的事情忙完之后，好好思考一下。

经过紧张的排查，夏忙得出的结论是，网络中心的一台交换机出了故障，夏忙迅速联系网络中心并启用了备用的交换机。20分钟后，网络恢复正常。

趁着尘埃暂定，夏忙赶紧翻资料，能给目前无序的忙乱状态理出一个解决思路。他发现，对于突发事件，最重要的是避免业务中断。对此，首先要确定突发事件管理流程，通过区分突发事件的优先级来确保流程的有效执行。显然，每个人都会认为自己故障是最紧急的，因此必须理清是火烧眉毛还是常规慢性病。

夏忙反思，网络中心那台出故障的交换机上连接着公司的销售部邮件服务器、库存数据库服务器、人力资源服务器，这一事故将直接影响到公司内关键部门的正常生产，应该属于紧急一级，如果不尽快处理将发生一级生产事故；而急脾气同事的事件则属于一般级别。因此先处理网络中心交换机问题是对的。

但是自己在紧急事件的处理工时上把握不够，刚才用了大约3个工时来处理交换机的问题。那么如果当自己在规定的时间内不能解决或没有解决某个突发事件时，又该怎么办？一般来说，如果不能在规定时间内解决，需将处理任务交给更有经验的支持人员。这叫突发事件升级，通常有两种方式：

一、职能升级，安排更多的专家或授予更多的特权以解决事故；

二、层次升级，出现在所需的权限和资源不够的时候。

突发事件管理可以帮助IT部门更加系统、快速地处理突发事件，但是只是规范处理过程，以尽快恢复故障。好比是急诊抢救，治标不治本。

要使突发事件管理有质的提高，治标也治本，一种切实有效的方法就是问题管理流程。

小贴士：

当IT服务台必须同时处理数个突发事件时，由于受时间、资源和人力等的限制而无法实现时，首先要排定处理的先后次序，针对不同的优先级处理。

确定突发事件处理优先级，需要综合考虑突发事件的影响、紧迫性、大小、范围、复杂程度和当前可供资源。

因理想而忙碌，勿因忙碌而失去理想！

解决了突发事件，正赶上十一放长假，夏忙去了趟华山，彻底休息了一下。

10月8日一大早，夏忙的电话就响个不停。也难怪，一上班大家就忙着收邮件，积累了几天的邮件把服务器搞得巨慢；许多节前已经预约的客户需要尽快联系，可邮件一遍一遍就是发不出去；网络更是不知犯了什么病，很多机器死活上不去网．．．．．．一整天，夏忙都在忙来跑去解决问题，面对抱怨，连解释的时间都没有。

晚上10点，总算有点头绪。夏忙坐下来，才想起自己几乎一天没吃饭、没喝水了。其实想象得到，每次长假后的第一天对IT人员来说都是黑色的，这和过节一样已经成为惯例。

喝了一杯水、吃了点面包、点上一支烟，夏忙回忆起这一天所干的事。长假过后，收邮件高峰会有网络堵塞，南方潮湿闷热的天气也会使得本来条件就差的机房服务器出现接触问题。

趁着发牢骚的时间网管们开了个小会，自学了几天IT服务管理的夏忙发现，事实上，今天他和其他两位同事的很多工作具有一定的重复性，业务等几个部门出现的IT问题几乎都是一样的。既然有规律可以循，是不是有办法加强防范，结局岂不皆大欢喜？

夏忙想起几天前做过的ITSM的培训，其中有一段说的就是问题管理，说白了就是“归堆儿之后再分类”，要求建立一个知识库，把以前发生的众多问题进行归纳总结，找出规律对号入座，同时总结经验不断丰富。

大道理谁也会讲，但夏忙还是不太理解。每天记录发生的问题，隔段时间再进行归纳总结和分类，多麻烦啊！本来工作量就大，哪有时间写日志呢？正因为有这样的想法，夏忙一直没当回事。不过今天看来，如果有这样的一个知识库就不至于这么狼狈。

其实无论什么公司，员工对IT的需求都有一定的共性。只处理不分析、不总结、不改进的IT永远只能是重复劳动。而如果通过引入问题管理，建立一个知识库，将众多问题归纳总结，找出规律加以实践，同时加强防范，不仅提高了效率，活也在一定程度上“少干”了。

夏忙越考虑越觉得有意思，于是打电话给上次给他讲课的蒋得明老师。面对渴求上进的夏忙的困惑，老师打了几个比方：事故管理是“救火”，问题管理是“消防”；事故管理是有病治病，问题管理是预防和保健。具体来说，滚滚来贸易公司在IT管理上，目前仅仅解决了如何规范地消除事故，而没有做到找出导致事故的原因并彻底解决问题。

蒋老师还说，在现实中，问题是无法避免的，有技术架构、产品缺陷、操作失误等等很多原因。夏忙又头疼了，这么多的原因怎么分类呢？

蒋老师继续说，对问题的归类直接决定着问题管理的效果，问题归类涉及五个方面：确定与问题相关联的领域，比如硬件、软件等；影响度，问题对业务流程的影响程度；问题需要得到解决的紧急程度；优先级，综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序；状态，描述事故目前所处的状况。

另外就是找原因，包括现实的原因和潜在的原因，当发现更好的或新的应急措施时，问题管理还要将其在记录中更新以便事故控制使用。

从此，滚滚来公司IT部门的公共文件夹多了一个文件夹，网管们记录每个问题的现象、原因和解决细节。

一个月下来，居然积累了300多个问题，共分了16大类，700多个原因。看着眼前的成就，夏忙有了底。

有了这个草创的“知识库”，夏忙的工作进入了快车道，进入了“主动治本”阶段。此后，大家对夏忙所在的IT部门有了好评，意见明显少了。

小贴士：

问题管理乍看起来对于IT人员来说是个费时间的活，但磨刀不误砍柴功。有了这些积累，加上分类、分析、预防等工作，效率明显提高了。对于IT人员来说，关键是排除抵触和为难情绪。

如何提升IT服务效率

如何提升IT服务效率，提高IT资源的利用率，发挥IT资源的最大效能，降低IT服务成本，量化IT产出，一直是IT管理者面临的难题和挑战。

IT服务管理（ITSM）可以形象地称为IT管理的“ERP解决方案”。IT服务管理是用来提升IT服务效率，协调IT服务部门内部运作，改善IT服务部门与业务部门的沟通，帮助企业对信息系统规划、实施和运营进行有效管理的方法。IT服务管理结合企业的环境、组织结构、IT资源和管理流程的特点，从流程、人员和技术三个方面来规划企业的IT结构。它强调企业的运营目标、企业需求和IT服务的交付相协调一致。

从组织层面来看，它将企业的IT部门从成本中心转化为服务中心或者利润中心；从具体运营来看，它改变传统的以职能、技术为中心的IT管理方式，以流程为中心，从复杂的IT管理活动中梳理出那些核心的流程，将这些流程标准化、规范化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标以及各个流程之间的关系，实现从传统的技术管理向流程管理，再向服务管理的转换。

11月1日，总经理召集各业务部门开会，简直就是一个批判会，总经理对10月各个部门的表现都不满意，特别是销售部门，惟独对IT部门提出了表扬，这让夏忙有一些宽慰.第二天．好不容易轻松一点的夏忙晚到了公司一会，半路接到公司里电话，这个说有一封很紧要的邮件一直没法收；那个说说好要给一个重要客户把报价发过去的，但是现在也不能发„„

原来是公司的邮件服务器出问题。可是昨天下班的时候这邮件服务器还好好的呀，夏忙赶紧给轮值的小欧打了个电话，问他昨天晚上都干什么了。

原来在总经理训话结束以后，销售经理就立刻召集了销售部门人员开了个会。为了改变目前的状态，销售部门讨论的结果是改变现有的工作流程。昨天晚上加班开完会确认了新流程后，销售经理把小欧找来要求系统也随着这个新流程做些更改。于是，小欧就根据销售经理的需求更改了几个参数。“改完后我仔细检查了一下，没发现什么问题呢。谁会想到邮件系统会出现问题呢？”小欧也很委屈。

夏忙明白了怎么回事以后，赶紧亲自到服务器上去恢复原来参数，让邮件服务器先正常工作。这一天夏忙没干别的，他花了整整一天的时间处理销售经理递交过来的需求。夏忙发现，销售经理拿过来的需求，有一些根本就不合理的。于是，夏忙又去找来销售经理“论理”。两人分析了半天，才讨论出了双方都满意的解决方案。

这事就已经够折腾的了。但是，由于11月份IT部门在忙着一个新系统的安装，所以这事完了以后夏忙一直没来得及跟整个IT部门讨论。

哪里想到这个月听了总经理一通训话以后，各个部门都比较积极地革新业务流程。采购部、人事部、财务部„„在那几天纷纷都来找IT部门来改流程、改参数。这下惨了，几乎每次更改后都出现了问题。接连几天夏忙更忙了，接连解决更改后出现的问题。

累得一塌糊涂的夏忙一闲下来就寻思：这不行呀，总经理训一次话就出现了那么多问题，万一他再训一次话，岂不是又完了；再说了，就算是总经理不训话了，业务部门还是会经常提出要修改系统配置等问题的，毕竟对业务部门来说，“变”是件好事。如果还是像过去那样随便变更，IT部门迟早要被这无数的“变更”给折腾惨了。

夏忙心想，还不如趁这个机会建立一个变更管理的机制。这样，一旦业务部门有了新业务、新变化、新流程，需要IT根据这新情况进行变更的时候，IT部门可以事先知道。

紧接着，夏忙就针对变更管理这个问题看了很多专业书籍，同时还虚心向同行请教。忙了半个月后，夏忙终于设计出了自己的变更管理流程。

夏忙自己动手给IT部门制定出了一个明确的需求变化表。用户有变化需求时必须按照手续提交。拿到需求表以后，IT人员也不能马上修改程序，而是应该判定此需求是否合理，是否会对以前的系统以及其他系统造成影响，必要的时候要与业务部门召开专题讨论会，讨论具体修改事情。同时，在内部网站中的IT服务专栏发布IT作业公告。相关部门如果有异议，可以在反馈期之内反馈。

如果判断通过，也不随便就做更改，而是提出明确的时间表、修改方法和意见，征求业务部门同意后，按时按量完成。

变更实施完毕以后，还要对变更的实施情况进行总结和评价：变更是否成功实施，业务部门是否满意等；变更是否还有遗留问题，是否存在副作用。

“虽然总经理的训话害得我那么苦，但是就这个机会完善了变更管理流程以后，就再不怕其他的变更了，也算是没有白忙乎。”对于这个月的工作，夏忙还是很有成就感。

小贴士：

实施变更管理流程过程中，有两个要素很重要。

其一，要转变IT工程师的观念和行为。变更管理流程的实行，刚开始的时候，对IT工程师的行为是一个约束。工程师对系统做任何修改、调整，都需要在变更管理系统申请、备案。因此，需要加强对IT工程师的宣传和要求，转变观念，使其能够接受并习惯。

其二，要明确职责。变更管理包括诸多流程，也涉及不同部门、不同岗位的人员。因此，需要界定各方人员的职责。如变更管理经理的职责，相关部门人员的职责，等等。只有职责清楚，各项职责执行到位，变更管理流程才能有效落实。因理想而忙碌，勿因忙碌而失去理想！5 服务级别管理

轻重缓急要掌管

前几个月一直表现亮眼的IT部门最近成了老板的心头好，员工们的抱怨没了不说，还进行了好几项突破性的改革，一派鸟枪换炮的新貌。年关将近，夏忙他们几乎看到了可观年终红包的招手。

这天，本该春风得意的夏忙长叹了口气：“唉！”其他人忙问：“小夏，你怎么了？连变更管理、突发事件管理„„这样的头疼事件都能解决，你还会被难倒不成？”夏忙又叹了口气，说：“各位有所不知，万里长征也不过走出了几小步。前几个月的工作尽管卓有成效，但跟接下来这个月要面对的事情一比，简直就是小巫见大巫。一不小心，我们全体同仁煮熟的鸭子红包恐怕就要飞了。”

这可不是夏忙小题大做，让他头疼的正是号称IT服务管理最大难题的—服务级别管理（SLA）。

对此，夏忙可有切肤之痛。得到同事们肯定了的IT部门是更加勤快了，但有时候却拣了芝麻丢了西瓜—一次，在他忙着花半小时修理打印机的时候，服务器由于病毒入侵而瘫痪了整整20分钟！公司的网上交易也因此停顿半天，老板的雷霆发了足足有90分钟。

什么是服务级别管理？简单地说，建立一套规则，当企业中有多个不同需求同时发生时，应该先响应谁的；以及对于不同的需求应该分配多长的时间。

“还是服务级别管理没搞好啊！”夏忙感叹。“我们IT部门应该有一个清楚的清单，列举出我们能够提供哪些服务，以及定义好各种业务部门要求提供的服务的级别。哪个级别高，哪个级别低，级别高的优先响应，级别低的等一等；规定问题的响应时间极限，哪个问题可以等上2个小时，或者等4个小时，哪个一秒钟也不能等„„”

听来很不错，不过要想搞好服务级别管理，可不是IT部门自己关上门来定一套规矩就行的，夏忙之所以谈“服务级别管理”色变，就是因为知道：服务级别管理的最大难度，在于定义各种服务的级别，而且不同企业也大不相同。

因此，IT服务级别的制定必须是业务部门与IT部门共同沟通的结果——服务级别协议。IT服务部门在对IT基础架构进行服务级别设计时，就必须充分调查和了解真实的业务需求。夏忙花了大量的时间和业务部门进行全面沟通。

他不仅调查了业务部门对当前服务级别的体验（Perception），还在这个基础上帮助他们分析和梳理那些真实存在却又还未明确的业务需求。

为了避免重蹈其他公司推行服务级别管理失败的覆辙，夏忙归纳出了几条“黄金法则”：1．在服务级别协议中业务部门看不懂的日常术语需要学习。2．把握好重点业务流程、定期的监控和回顾、适当简化服务级别管理的流程。3．综合考虑资源水平和成本，避免对服务水平不切实际的承诺；4．IT与业务部门持续分享流程经验，不断进步。

总之，SLM 的任务就是要在 IT 服务质量、客户关系、以及 IT 服务成本三者之间博弈，寻找最有利的平衡点。

小贴士：

在实际运行中，服务级别管理是个动态的过程，是可以调整的，大可以先简单制定，然后根据实际情况进行调整。

经过小半年的忙活，眨眼到了年底，夏忙的年终红包丰厚了许多，他也从一个PC修理工成长为系统管理员，“夏忙”成了“夏工”，修机器、扯皮、投诉离夏忙越来越远，转而代之的是IT规划，开发新系统、数据挖掘。

其实，夏忙知道自己离真正的IT服务管理还有不少的路要走，比如合理化规划目前的系统资源，开发新的应，比如进行企业的资产管理，再比如怎么才能让IT为管理搭好桥。

这就是夏忙从瞎忙的IT网管成长为合格的IT规划者的道路，也是IT服务管理的灵活运用。

做好三个心理准备

做IT服务管理，并不是IT自己的事情，因为IT最终也是要为管理服务的，应该说，业务部门也要参与到IT服务管理工作中。所以，无论是IT部门，还是业务部门，做IT服务管理都得有三个心理准备。

一是要有改变工作方式和规则的准备。IT部门和业务部门都有习惯性的工作方式，他们会继续采用原有的流程、做法，甚至会拒绝接受新的工作流程、方式。因此，为了保证实施效果，需要把IT服务管理的实施结果与IT人员和业务人员进行充分沟通，使他们能够充分理解IT服务管理的实施对他们带来的影响、好处，知道如何去做才能达到IT服务管理的要求。

二是不要操之过急。IT服务管理本身是由国外引入的，与国内的IT管理方式有一定区别，再加上前文提到习惯改变的难度，可以说，做IT服务管理要有磨合期，也是一个循序渐进，螺旋式上升的过程。做好打持久战的准备，磨合期内，不断调整，不断进步，才是正道。