让IT人员不再当“救火队员”

让IT人员不再当“救火队员”
让IT人员不再当“救火队员”，ITSM咨询顾问常用此话来解释ITSM的
作用。

事实上，不仅如此，ITSM还能从本质上提升IT部门的服务水平。

不
过，大多数人对ITSM知之不多。

下面的案例以某跨国公司中国分公司遵循时
下在美国备受关注的萨班斯-奥克斯利（SOX）法规为线索，详细剖析如何通
过实施ITSM来提升IT部门的服务能力。

其中不仅有对ITSM、ITIL的探讨，
还有对SOX的研究，希望对读者有所帮助。

1准备出发
X公司是一国际知名制造业集团，荣登美国《财富》杂志100强，其中国分公司的IT部门设在北京，所承担的主要任务是在公司总部IT部门的技术支持下，实现技术的本地化，提供符合中国本土业务需求的IT 服务。

目前，中国IT部门提供的服务包括:
● IT应用系统(Application)的运维管理，包括SAP系统、Oracle财务系统、库存管理系统、邮件系统等;
● IT基础设施的运维管理，包括机房和服务器管理、桌面系统、LAN、网络监控系统等。

2002年7月，美国国会正式通过了Sarbanes－Oxley法案（简称SOX法案），明确要求管理层对公司财务信息披露和内部控制效力负有直接责任，公司的内控措施应由管理层声明有效，并由独立审计机构出具内控审计意见提交给美国证监会（SEC）。

作为一家在美国上市的公司，X公司全球各分支机构都将面对严格的SOX审计，SOX法案中的第404条款要求公司在财务报告方面加强内控，考虑到IT和财务报告的关联性，IT 也需要加强控制以达到和SOX合规。

另一方面，随着业务和用户需求的提高，公司管理层对IT部门提高工作效率，降低运营成本的要求也越来越明确。

他们认为IT部门做事没有可循的流程规范，IT人员的角色和职责定义不清晰。

面对来自内外两方面的压力，X公司中国IT部门决定改变被动的局面，建立起基于流程的IT
管控体系，从根本上提高IT管理和控制能力。

选择ITSM
长期以来，X公司的中国IT部门与IT服务供应商以及第三方咨询一直保持着良好的合作关系。

当科索路咨询公司参与到项目中后，开展有效和高效的IT服务管理成为它为X公司开出的首张药方。

咨询人员认为，IT的SOX合规审计需要落实到企业对IT的有效管理控制上来，而参照ITIL（IT Infrastructure Library，IT基础架构最佳实践库）实践模型建立IT服务管理流程是最好的解决方法之一。

首先，ITIL是行业的最佳实践，是被无数实例证明了的行之有效的IT服务管理事实上的标准，ITIL已经得到X公司总部的认可; 其次，SOX合规审计过程中，IT控制目标重点集中在IT的运维管理，依照ITIL建立IT服务管理流程能够很大程度地满足合规要求; 再者，ITIL是一套通用的交流语言，它基于流程、面向业务、规范但不死板，可以很好地发挥企业IT管理的灵活性和能动性。

考虑到以上几点，X公司IT部门决定在参考ITIL模型的基础上，结合自身管理经验，在咨询人员的帮助下进行IT服务管理流程的建设和改造，为即将到来的SOX合规审计做好充分准备。

制定规划
ITIL的流程涉及面广，关系复杂，“一拥而上”有很大风险。

同时企业希望IT服务管理体系的建设能够首先考虑如何帮助其通过SOX的合规审计。

因此，本着“针对需求，分步实施，快速见效”的原则，企业在咨询人员的帮助下建立起信息系统质量管理体系，从流程建设着手，引进先进的管理控制方法理念，以确保IT部门按时通过SOX合规审计，并以此为契机，提高IT部门的工作效率和服务质量。

根据方案规划，X公司IT部门SOX合规项目分为三个阶段。

第一阶段分析客户现有的IT管理模式，评价分析现有IT服务管理流程的成熟度，对照SOX要求，参照ITIL最佳实践进行IT服务管理流程改善规划。

第二阶段结合业务需求、管理经验和IT控制目标，针对突发事件管理、变更管理、服务级别管理、IT服务连续性管理、安全管理等流程管理模块，从管理策略、规范、流程、操作到组织、文档、工具等多个角度建立全方位的信息系统质量管理体系，实现对IT的有效管理控制。

第三阶段则是根据SOX的审计要求，分析X公司的IT风险，制定风险控制矩阵，分析现有控制和目标的差距，并提出合理可行的改进步骤。

帮助客户制定定期测试方案，为最终通过SOX合规审计做好准备。

按照SOX的要求，企业仅“存在”内控机制是远远不够的。

企业必须进行定期的有效性审计，连同内控措施的缺陷以及改进计划一起向美国证券交易委员会做出汇报。

因此，在项目过程中必须始终强调服务管理流程的合理性，持续改进的可能性以及审计监控的有效性，并采取措施保证项目结果能够收获预期的效果——达到SOX合规要求，提高IT服务管控能力。

2突发事件管理和问题管理
突发事件管理与问题管理直接影响IT服务对业务的支持程度和客户满意度，它们常常是IT部门提高IT 服务质量的着手点。

对于IT服务中出现的非正常情况，突发事件管理治标，问题管理治本。

标本兼治正是IT服务的立身之本。

企业现状
X公司IT部门在项目开展前已设立了服务台。

其主要服务是对突发事件进行记录，并能解决常见的突发事件和服务请求，将大多数事件升级给二线、三线。

由于这些服务都是随机地设立起来的，并没有进行规划和优化，所以服务台的一线解决率较低; 突发事件在一线与二、三线之间的升级途径不明确，在突发事件数量高峰时，人员调配出现困难。

同时由于没有对突发事件处理的经验进行分类归纳，有些事件一而再、再而三地发生，导致IT部门员工效率较低，专业技术人员无暇顾及寻找导致突发事件的根本原因。

这些情况是日积月累造成的，IT部门管理者虽然感觉到这些问题的存在，也承受着来自客户方面要求改进压力，但短时间内也不知该如何下手。

图1 突发事件管理与问题管理的主要内容
SOX合规要求
SOX要求X企业提供可靠及时的财务报告。

IT服务中的突发事件和问题处理可能对生产、采购、销售、财务产生重大影响，并进而影响最终的财务报告。

所以IT部门需要对所有的突发事件和问题进行有效的内部控制，包括:
● 突发事件处理: 记录、分析、及时解决所有突发事件，即非常规事件;
● 问题处理: 通过细致的分析调查，发现引起突发事件的根本原因，并找到解决方案;
● 特殊突发事件处理: 建立紧急响应流程，处理与安全有关的突发事件，比如非法的系统登录。

ITIL的建议
ITIL描述的突发事件管理和问题管理能够满足SOX合规要求，并且能帮助公司摆脱面临的上述困境。

突发事件管理的主要目标是缩短事件处理时间，合理调配人员与提高客户满意度，尽快恢复正常服务，而问题管理的重点在于找到突发事件的根本原因，并彻底解决。

通过建立知识库，突发事件和问题解决中所得到的经验被固化下来，使服务质量得以持续地提高。

项目经验
理论指导实践，实践创新理论，开展ITIL项目的成功秘诀就是灵活地实施。

但是这个人人皆知的秘密常常最难实现。

究其主要原因，并不是因为照搬“教条”，而是不懂“教条”。

如果不理解ITIL为什么会采用这样的定义、流程、接口、关键成功因素，又怎么能根据现实情况，知道ITIL哪里该取，哪里该舍呢？
以下几点是在X公司的IT服务项目中被实践了的，其综合效果也得到了公司管理层与IT服务部门员工的肯定:
1. 定义突发事件的分类。

突发事件的分类直接影响事件的升级途径、影响程度和重要性分析。

比如与安全有关的突发事件，即使优先级不是非常高，根据SOX法案的要求，也应该尽快地被处理。

2. 定义突发事件的优先级。

突发事件的优先级可以根据影响范围、严重程度和时间期限来确定，预先确定事件优先级可以反映出业务对该类事件的要求。

X公司的IT部门通过定义事件优先级解决了资源的分配问题。

3. 定义事件升级途径，包括人员的角色和责任。

事件升级可以是横向的，即事件通过一线向二线、三线升级获得技术支持，也可以是纵向的,即将事件升级到管理层以获得更多支持。

定义事件升级的过程必须由相关人员协商决定，达成相互间的理解和共识。

4. 定义问题触发机制。

问题管理与突发事件管理中的流程、关键成功因素是不同的，问题管理的资源不能被挪用。

在规定时间内得不到解决的，对业务影响特别严重的，或者经常发生的突发事件都会升级到问题管理流程。

5. 主动地问题管理。

IT部门需要制定流程来定期对突发事件进行回顾，通过趋势分析发现系统中隐藏的问题。

解决这些问题有助于减少突发事件的数量，为知识库增加有用的解决方案，提高服务质量。

6. 二、三线知识的转移。

通过建立知识库，将突发事件与相应的问题相联系，二、三线及时为一线提供更有效的解决方案和变通方案。

X公司通过突发事件定义的关键字进行方案的匹配和查询。

知识的转移提高了一线的效率。

7. 绩效考核标准。

根据公司实际情况和最佳实践的建议，制定与IT服务目标相一致的考核标准。

比如对服务台，将突发事件数量、突发事件解决率、平均响应时间、平均解决突发事件的成本等因素作为考核标准。

8. 人员培训与教育。

培训可使IT部门的员工和业务部门代表具备所需技能，明确他们各自的责任和流程之间接口。

另一方面，员工常对新流程抱有抵触情绪，不能理解定期检查的必要性，这些问题也可以通过培训得到沟通。

3变更管理
为了适应不断变化的用户需求，为了纠正IT服务提供过程中出现的问题，企业的IT应用和IT基础设施经常需要进行变更。

但是变更并不一定往好的方向发展，失控的变更往往会导致新的突发事件和问题。

因此，企业需要实施有效的变更管理对所有变更加以控制，尽可能降低变更带来的风险和对公司业务造成的损失。

客户现状
就X公司中国IT部门变更管理的现状来看，不仅是使用者，包括IT部门自身也觉得不太满意。

首先，由于变更管理规范考虑不周全，以及部分IT员工对变更控制的认识不足，个别已经实施的变更请求没有审批者的签字，还有一些变更没有被记录，导致这些变更产生的新问题不能快速地定位。

另外，由于缺乏良好的变更评估、协调和控制机制，导致有一定数量的变更以“back-out”结束。

总的来说，X公司中国IT部门现有变更管理还有改进的空间。

SOX的要求
SOX的IT合规要求企业IT控制能够合理地保证财务相关的IT系统的升级和变更得到授权和测试。

为了做到这一点，IT部门必须确保对变更的有效管理和控制，主要包括:
● 变革请求的发起和控制: 保证所有变更请求服从规范并遵守变更管理的标准程序。

● 变更影响分析: 分析变更请求可能对IT基础设施及其功能带来的影响。

● 变更的控制: 对变更进行记录和跟踪，尤其是关系到大型复杂系统的变更。

● 紧急变更管理: 预先定义紧急变更，建立紧急变更处理流程来控制这些变更，紧急变更也需要得到IT 管理人员的授权并做好相应的记录。

ITIL的建议
ITIL要求变更管理能够做到以标准的方法和步骤高效快捷地处理所有变更，将变更对IT服务质量和连续性的影响降至最低。

因此ITIL的变更管理流程对变更请求、变更影响、变更批准等进行了管理和控制。

一般而言，典型的ITIL变更管理流程模块包括如下几项活动: 提交变更请求，评估变更的影响和风险，变更请求的审批，制定变更进度计划，协调变更的开发、测试和实施，变更实施后进行评估。

项目经验
在参照ITIL为X公司改进变更管理流程的过程中，咨询人员认为X公司的问题具有一定的典型意义。

因此在总结项目经验的基础上为企业落实变更流程提出了如下几点建议:
1．不同类型的变更有不同的工作流程。

企业应该预先按照紧急程度和影响大小将变更划分为若干个等级，比如预先批准的变更作为标准变更可由服务台负责完成，普通变更可以根据变更的影响再细分成若干等级，以及紧急变更等）。

然后为每一类型的定义标准处理流程，并加以记录。

这样可以提高变更管理的灵活性，避免单一流程妨碍变更效率的现象。

2．建立完善严谨的变更批准程序。

可以考虑建立企业的变更建议委员会，根据变更影响分析、变更的代价、变更的时机等因素对变更的批准给予建议，提高IT对变更风险的控制，降低变更可能带来的损失。

其次，要改变IT人员的思想观念，改变“变更批准是走程序”的看法，严格遵照流程办事。

3．在变更实施之后对变更进行评估。

在变更之后，要及时评估变更是否达到预期的效果，有无副作用。

并将相关文档和相关配置项信息进行更新，反映出变更的效果。

这种实施后的评估可以获得经验，便于今后变更管理质量的提升。

4．变更管理最好能和配置管理协调工作。

变更管理和配置管理是两个关系紧密的流程，它们可以有效地整合在一起。

配置管理的实施可以很好地支持变更管理的运作。

4服务级别管理
每一种产品都有说明书，以明确地向用户展示产品的功能、质量以及厂商的承诺。

服务则不同，人们一直
以来都很少要求服务出具说明书。

但如今，用户的这种对服务的放纵已日益显示出其弊端: 服务质量得不到保证，用户抱怨不断，而服务商则不是推诿搪塞就是根本不会写“服务说明书”……开展服务级别管理已经刻不容缓。

企业现状
X公司长期以来一直将其部分的IT业务进行了外包，因此拥有较为丰富的外包管理经验和健全的外包管理体系。

不过，尽管公司IT部门与外包商和外部服务提供商签订了服务合同，他们对企业内部的IT用户却没有任何的服务质量承诺，来自用户和高层的压力很大。

IT经理向咨询顾问诉苦道: “不是我们不想签订服务级别协议，我们想签！但是现在就连我自己都不明白我们能够就IT服务对用户提供哪些承诺，我们怎么敢签？达不到要求谁负责啊？”SOX合规审计迫在眉睫，如何开展SLM成为困扰她的一个大问题。

SOX的要求
在计算机信息系统普及的今天，公司的财务信息处理和披露基本上全赖IT的支持。

SOX对公司财务信息披露效率和质量的要求，很自然地就将压力转嫁到了IT系统之上——信息系统必须能够满足财务信息处理和披露的要求，必须能够协助公司的内控措施发挥效率等。

另一方面，SOX要求定期评估内控的效力，企业必须拥有一套科学客观的评价体系才能对IT服务水平进行评价。

因此，开展服务级别管理是企业进行内部控制的一个重要手段。

一方面，它能够保证IT提供的服务是符合SOX规定和业务需求的; 另一方面，它在协议的基础上定义了服务的绩效指标，方便了对IT服务进行管理和控制。

ITIL的建议
在ITIL模型中，服务级别管理被给予十分重要的地位。

服务级别协议（SLA）集中反映了来自服务提供（Service Delivery）各流程的用户需求，用量化的方式定义IT服务的能力（规模）、可用性、连续性和财务指标，帮助明确服务支持各流程的目标，使其能够提供合格甚至卓越的IT服务，从而实现IT服务绩效的持续提升。

可以说，服务级别管理是IT部门与用户联系的纽带，也是不断推动IT服务过程进行整体提升的引擎。

项目经验
像X公司IT经理这样的困扰，咨询顾问们已不是第一次听到了，在这通过分享顾问们在IT服务级别管理的咨询经验，希望能对IT经理们有所帮助和启发:
1．认真编制服务目录
编制服务目录是开展服务级别管理必要的准备工作，它定义了服务提供者所提供服务的全部种类以及服务目标。

许多企业的IT部门之所以不敢签订SLA，就是因为连他们自己都不了解自己的服务内容和服务能力，而编制服务目录就是一个绝好的梳理机会。

编制服务目录应该做到以下几点: 首先，服务目录应该以用户能够理解的语言进行表达; 其次，服务目录是公开的文件，应该能方便地被查阅; 再次，对每一项服务内容都应该明确服务的目标以及现状（即定义基线）; 最后，服务目录包括服务种类和标准都要定期更新。

2．正确制定并签署服务级别协议
SLA是服务级别管理的核心，因此SLA的制定和签署需要格外谨慎。

要确保SLA的有效性，应当特别注意:
(1)SLA应该建立在双方互信互谅的基础之上，是“婚约”而不是“卖身契”; (2)明确服务级别的管理对象，在详尽的同时做到重点突出; (3)详细描述并定义服务的绩效指标，做到量化、易懂和可行; (4)明确服务供求双方的责任和义务，缺乏对用户约束的SLA是难以发挥效力的; (5)声明达到某种级别服务水平的前提和假设条件。

对于像X公司这样对自身实际的IT服务能力还没有把握的企业，不必急于对服务级别水平进行规定。

IT 部门可以综合考虑基线水平与用户需求，定义初步的服务级别计划。

然后在与客户达成协议的前提下，经过一段试行，考察实际的服务能力，然后对服务级别进行修正。

3．服务水平的持续改进
签订SLA仅仅是一个开始，后续还需要大量的管理和监控工作。

合格的服务级别管理应该是动态提升的，它通过“明确需求－实施协议－过程控制－绩效检查”的管理循环缩短业务需求与实际服务之间的差距，达到IT服务水平的持续改进。

5业务连续性管理
业务连续性管理（Business Continuity Management，BCM）是指在重大的事故或灾难发生时，公司所采取的应对措施以保证核心业务的连续性，将公司的人员、财产、利益损失降至最小。

同时通过BCM能够及早确定可能产生的影响及对企业运作造成的威胁，提供合理的架构有效阻止或抵消不确定事件造成的威胁，保证企业日常业务运行的平稳有序。

IT业务连续性是公司业务连续性的重要组成部分，主要关注那些支持企业核心业务运作的关键IT服务的连续性，从而为公司总体的业务持续性提供支持。

企业现状
X公司正在制定整体的业务连续性计划BCP（Business Continuity Plan），要求各业务部门（包括IT
部门）提交本部门的业务连续性计划。

X公司的IT部门对于某些关键IT系统，在其项目实施时已经制定了相应的灾备计划，并对数据有定期的备份和保管机制，对机房环境、网络通信、主要设备等也采取了一定的安全保护措施。

同时IT部门拥有自己的备件库，其中设备可供灾难发生时使用。

但是，IT部门的这些努力都是分散孤立的，难以评判它们对IT业务持续性的贡献，也无法确定是否所有的关键系统都得到了足够的保护，是否满足各业务部门在灾难发生时对IT服务的需要？另外一些细微但非常重要的问题也没有得到定义。

比如由谁来宣布灾难发生？在灾难发生时，优先恢复哪些IT资源？如何调配IT 人员？如何通知受影响的业务部门？这些问题都需要通过全面的业务连续性计划来定义和实现。

SOX的要求
图2 IT业务连续性管理流程
SOX法案要求上市公司具有完善的安全策略和措施以保证业务的连续性，但并没有具体指明以哪种形式来实现。

通常，内部和外部审计人员都会通过寻找以下证据来证明IT部门已经采取了有效可靠的业务连续性管理:
● IT部门拥有业务连续性管理框架。

业务连续性计划、操作手册、配置文件等文档和备份数据被放置在安全的地方并能够在灾难发生时被获得。

● 连续性计划能根据业务或资源的改变做到及时的更新，通过制度化的演习和评估不断完善，从而保证其持续有效。

● 员工具有执行业务连续性计划的能力，明确自己在灾难发生时的职责。

ITIL建议
IT业务连续性管理是ITIL模型的十个流程之一。

ITIL认为，灾难是对服务或系统产生重大负面影响、需要巨大努力才能恢复原来的服务级别的事件。

而IT服务持续性管理的目标就是保证特定的IT设施和IT服务在灾难发生后的规定时间内得到恢复，从而支持业务持续性管理。

IT服务持续性管理流程如图2所示。

实施经验
IT服务持续性项目随公司结构、IT服务内容的不同，在具体实施时需要灵活进行。

过分拘泥于ITIL最佳实践并不可取，下面的对持续性计划的认识也是在实践中不断摸索而来，希望对读者能有所启发。

1. 业务持续计划(BCP)与灾难恢复计划(DRP)的关系。

一般来说，BCP着重于根据业务影响分析（BIA）和
风险评估的结果，制定相应的策略使系统和服务的持续满足业务要求，而DRP着重从技术角度解决系统恢复问题，将流程和策略细节具体化到操作层面，以满足BCP对系统和服务的定义。

DRP可视为BCP的附件，也可单独存在。

2. 范围定义。

并不是所有的IT资源和应用都会被包含在IT服务持续性计划中，比如由业务部门自行维护的系统，存放在公司电脑上的私人数据，整体外包的IT服务等。

IT连续性计划中所定义的范围需要经过管理层和其他业务部门的同意。

3. 灾难定义。

灾难不仅包括火灾、水灾、雷击等自然灾害，恐怖活动、黑客入侵、暴力、抢劫、绑架等犯罪活动，也包括严重的硬件错误或突然停电等无法预测的，对服务造成重大威胁的事件。

灾难可以通过情景定义，预先制定好量化的标准，从而使管理层在判断是否发生灾难及其影响程度时有所依据。

4. 业务影响分析(BIA)。

进行业务影响分析的目的是帮助IT持续性管理人员了解哪些属于关键业务流程及其发生中断后可能对组织产生的损害或损失、理解业务对具体的IT服务依赖程度和要求，从而为IT服务恢复的优先级的确定、方案的选择提供依据。

业务影响分析是与客户交流的过程，客户在交流过程中描述信息系统对业务的作用和系统崩溃对他们的影响，确定可接受的最长恢复时间、数据恢复的时效性要求以及紧急情况下所需要的最基本的IT服务等。

5. 业务要求与预算的平衡。

IT服务持续计划受限于公司的业务持续性计划，需要根据业务影响分析的结果，做到业务部门对IT服务持续性要求和公司预算之间的平衡。

6. 规避方案、应急方案与恢复方案。

在制定业务持续性计划时，这三种方案都必须被包括。

规避方案可以与IT服务的日常管理相结合，比如添置防水防火设备，安装监控设备; 应急方案强调在短时间内恢复关键服务，比如租借设备、在临时办公地点开展服务; 恢复方案关注于整个系统在一段较长的时间内逐步恢复。

7. 测试与教育。

持续性计划的测试非常重要，有两种方式。

一种是假定情景，对相关文档和流程进行检查，确认持续性计划是否支持从灾难前、灾难发生、紧急应对到服务恢复的一系列活动。

另一种是模拟演习，这种方式能使IT人员更明确他们在灾难发生时所负的责任，更好地查找、更新和完善在计划中任何可能存在的漏洞，同时通过演习加强IT部门和业务部门的沟通协作。

8. 计划维护。

一个BCP必须周期性地加以检查和维护。

一旦有新的系统、新的业务流程、加入企业的生产系统或者信息系统，就应该启动这种程序。

除此之外，像联系人名单的更改这样微小的变动都可能触发BCP 计划的更新。

BCP的维护应该是变化和改进的结合与不断促进。

考虑到其变更的需要，可以将持续性计划作为配置项来管理，并指定专人负责进行维护。

6征程无尽头
在项目启动实施半年之后，X公司中国IT部门终于迎来了期中考——公司全球SOX合规IT内部审计，获得了一致好评。

短暂的庆祝过后，X公司中国IT部门开始思考如何巩固和发挥SOX合规项目的作用。

回头看来，此次SOX合规项目的成功向我们表明这一轮SOX合规审计浪潮是企业开展IT服务管理，实施ITIL/IT服务管理流程的新机遇。

X公司案例给了我们很多启示:
首先，开展IT服务管理需要明确的管理目标。

X公司实施服务管理的目标很明确: 通过SOX合规审计，为项目的推进提供了持续有力的推动并指明了管理重点。

所以X公司目前实施的服务管理流程都是以提高IT 控制能力，加强IT服务可靠性和连续性为目的而有针对性地开展的。