1 基于ITIL的IT服务管理引言
　　二十世纪八十年代末形成的IT lnfrastruclure Library (信息技术基础架构库，简称ITIL)已经在全世界成为事实上的IT服务管理的最佳实践和标准。基于ITIL的IT服务管理作为一种新的IT管理模式，它以流程为导向、以客户服务为中心，提升了企业IT运营效率和客户对IT部门服务的满意度。这种IT管理模式在欧洲和北美等国家和地区得到了广泛的应用．近年来在我国也得到了越来越多的关注和应用。
　　ITIL服务器管理主要由服务支持(Service suppon)和服务交付(Service Dilevery)组成，这两者是整个ITIL框架的核心。ITIL服务支持主要论述客户和用户如何获得恰当的服务来支持他们的活动和业务，以及这些服务怎样得到支持。它主要是由下列模块组成：事故管理，问题管理，配置管理，变更管理和发布管理，外加一个服务台。
　　2 应用于ERP系统的事故管理流程概述
　　事故管理是服务支持中应用得最为广泛，也往往是第一个被实施的模块在ERP系统服务管理中也同样如此。本文针对ERP系统的特点和业务运作对ERP系统要求的特殊性，根据大型跨国公司ERP服务部门的IT服务管理的经验和实践来具体谈谈事故管理在ERP应用系统中的应用流程和最佳实践，特别是其不同于IT基础设施事故管理的特点。
　　这里假设大型跨国公司采用基于ITIL的IT服务管理系统来支持IT服务管理流程。同时为叙述方便，我们采用一些ITIL和业界通用术语来表述观点。
　　1)一般用户:运用ERP系统进行业务操作的普通业务用户。
　　2)关键用户:对所分担的业务有较深的专业知识和业务能力，同时对ERP操作比较娴熟，既能解决和业务相关的问题，也能解决一般用户碰到的常见的ERP操作问题的用户。
　　3)事故单:由关键用户通过IT服务系统提出的事故解决请求记录。
　　4)事故经理:负责处理事故的ERP功能支持人员。每一个事故均有一个事故经理。
　　5)工作单:有些事故需要其它ERP模块支待组或其它应用系统支持组参与解决，故在事故单下由事故经理发出工作单去寻求合作支持。
　　随着ERP系统的不断发展和完善，现在ERP系统已经渗透到整个公司的所有业务运作中了，ERP系统出现的问题有时候会严重影响到公司业务的运作。系统的复杂性和业务部门对ERP系统的高度依赖性使得ERP系统的事故解决其有以下两个特点:
　　1)要尽可能快地解决事故，这就要求整个事故管理流程简练快捷，尽可能减少从用户到相关ERP支持人员的中间环节;
　　2)事故的解决过程中ERP支待人员需要和用户从技术和业务层面不断沟通和互动，这就要求ERP系统的支持人员不仅需要具备相关模块的ERP系统技术，同时也要有相关业务领域扎实的业务知识。
　　在实践中，应用于ERP系统的事故管理一般有三种流程，如图1所示，不同的公司会根据需要选择不同的流程。

图1 事故管理在ERP系统中的三种流程

　　流程1:采用传统的事故管理流程，即用户向IT服务台寻求帮助，IT服务台判断事故的类别，若是和ERP系统相关，则转发到二线ERP服务台，再由二线ERP服务台判断并转发到相关的ERP功能支持组去分析和提供事故的解决方案。设立二线ERP服务台的原因是因为ERP系统的复杂性使得普通的IT服务台难以准确判断某一事故该由哪个ERP功能支持组去负责解决。
　　这种流程的优点是该流程和应用于基础设施的流程基本吻合，强调了事故管理流程在整个IT服务管理中的统一性。而缺点则是显而易见的，IT服务台和二线ERP服务台职能重叠，从而延长了ERP功能支持人员对事故的响应时间。
　　流程2:设立关键用户，在流程中跳过IT服务台，由关键用户判断事故是否属于ERP范畴。若是和ERP系统相关，则联系二线ERP服务台，再由二线ERP服务台判断并转发到相关的ERP功能支持组去分析和提供事故的解决方案，流程2显然是流程1的改进版，取消了IT服务台，从而一定程度上加快了响应时间。但关键用户和二线ERP功能支持组之间依然没有直接对话，从而影响了关键用户和ERP功能支持人员的直接互动。
　　流程3:设立关键用户，在流程中跳过TT服务台，不再设立二线ERP服务台，由关键用户判断事故是否属于ERP范畴。若是和ERP系统相关，则直接联系相关的ERP功能支持组，由该ERP功能支持组去分析和提供事故的解决方案。
　　无疑，流程3是最为快捷有效的，也最适合ERP应用系统的特点和业务要求，充分发挥了关键用户的作用。许多对ERP系统的时效性和依赖度比较高的行业普遍采用这种流程。
　　本文以流程3为基础讲述应用于ERP系统的事故管理流程的最佳实践及应用特点。
　　3 事故管理流程在ERP系统中的最佳实践及应用特点
　　由于ERP系统与业务运作紧密相关，为提高IT部门的响应速度和与用户的沟通效率，协调IT内部各支持部门的合作，应用在大型跨国公司ERP系统中的事故管理最佳实践流程如图2所示，它是前面提到的流程3的具体化。该流程具有下列特点:

　　图2 事故管理在ERP系统中的最佳实践流程

　　A.充分发挥关键用户的作用
　　在用户中设置关键用户，一般用户在碰到ERP方面的问题时，先求助于关键用户，若关键用户解决不了，则由关键用户直接在IT服务管理系统中登记一个事故单，然后直接转到相关的二线IT ERP支持组。一般用户不直接联系ERP支持组。
　　在这里关键用户起着一线支持的作用，他们不仅能回答诸如如何操作系统等和培训相关的问题，还能帮助IT部门解决简单的ERF相关的常见事故或是更快地判断事故类别并向相关的ERP支持组寻求帮助。可以说关键用户不仅是一般用户和ERP支持人员间的桥梁，而且帮助IT部门解决了一些常见问题从而使IT部门能更好地集中精力处理复杂的事故。
　　B.强调单点联系
　　当用户遇到和ERP相关的问题时，根据用户自己所在的部门和业务范畴，自然而然地把事故单提交给相对应的IT ERP支持组，但由于ERP系统的复杂性和各ERP功能支持组的分工不同，有些事故的解决可能需要其它ERP功能组参与解决其中某一部分的问题。对此类情况一般有两种处理方法:方法：1是把事故单直接交给另一个ERP功能组去负责解决.即事故经理随着事故单在不同的ERP功能支持组的转移而变化;方法2则采用单点联系，即始终由第一个接到事故单的事故经理负责该事故的最终解决和与用户的沟通，同时协调所需的相关ERP功能组共同解决事故。
　　从用户的角度来说，用户要求的是所碰到的问题能尽快得到解决，并不关心在IT内部是怎么解决的。方法1可能会给用户一个被“踢皮球”的感觉，这显然会影响客户的满意度。从IT服务的角度来说.单点联系简化了支持流程，明确了责任，避免了可能出现的“踢皮球”现象，从而提高了IT运作效率。故而方法2从目前来说是一种最佳实践。
　　既然面对用户的事故经理保持不变，则需要由事故经理通知参与的其他功能组可能需要做什么，及希望什么时候完成。在IT服务管理系统中，事故经理可以运用工作单的方式来通知相关的其他功能组协助事故的解决。一个事故单可以带多个工作单，工作单约定的最迟解决时间不应迟于事故单根据事故的紧急性定义而要求的最迟时间，不然的话会影响服务级别协议（SLA）。只有在某一事故单下的所有工作单都关掉后，该事故单才有可能被关掉。工作单的负责人只对事故单的事故经理负责和沟通，这样既使用户不用跟多个部门的人沟通，又使事故单的事故经理能完个了解和协调事故的解决。
　　当然，单点联系并不意味着凡是第一个接到事故单的ERP支待人员必须是该事故的事故经理〔若关键用户把事故单指派给了错误的ERP支持组，经过分析应第一时间把事故单转移出去，并通知相关的关键用户。
　　C.事故的影响度和紧急性的判断以及事故优先级划分
　　事故的影响度和紧急性是事故的基本属性。紧急性指的是业务或用户可接受的解决事故的耽搁时间，它直接和SLA相关。影响度由该事故对业务的影响程度决定，亦即事故可能或已经引起对所约定或期望的服务水平造成的偏离程度。事故的优先级取决于事故的紧急性和对业务的影响度，它决定事故处理的先后次序。
　　紧急性的级别可以根据公司的业务需求来定义，一般可分为五个级别，每个级别定义解决事故的目标期限、对事故的第一响应时间和对用户的沟通频度等服务级别协议。影响度则一般分为高中低三级。由紧急性和影响度组成的优先级矩阵如表1左边部分所示，表1右边部分为简化的服务级别协议。

　　表1 事故的优先级矩阵及服务级别协议

　　表1中带斜线部分的组合不存在，优先级I(组合H/l)是最高的优先级，优先级2,4,5(组合M/l ,M/2, L/2)是高级别的优先级，它们都需要PT相关服务部门做出7x24小时的全天候响应。优先级6-II(M/3,L/3, M/4,L/4, M/5,L/5)是正常的服务模式。优先级3(Il1)是一个特殊的优先级，一般仅为公司VIP成员而设。从表1中可以看到，紧急性决定事故解决的目标期限，影响度决定了解决紧急性相同的事故的先后次序。
　　在具体判断事故的影响度和紧急性时，一般有共种方法一是由IT支持人员决定;二是由关键用户决定;三是由关键用户和IT支持人员共同决定。
　　由于ERP系统与业务运作紧密相关方法一一般只适用于与基础设施相关的事故管理。方法二有一定的局限性，有时用户会不恰当地提高事故的优先级。因为用户总是希望任何事故都能解决得越快越好，但这会增加IT部门的工作强度，从而最终增加公司的运营成木。而作为ERP支持人员、他们具有足够的业务知识去判断事故可能引起的业务影响，而且能判断有没有应急备案。因此关键用户和ERP支持人员共同商量决定事故的影响度和紧急性可以达到服务和成本的最佳平衡。所以在本文中我们推荐用方法三。
　　D.事故危机管理
　　在实践中，有时候会发生优先级为1的严重事故，例如ERP系统宕机，大量用户无法登陆ERP系统关键的系统接口或ERP模块不工作等。这类事故的很大部分往往是由相关的基础设施或其他应用系统的严重事故引起的，例如服务器、操作系统、网络、数据库、接口等意外地不能正常工作等。因此这类突发性且产生大范围重大业务影响的事故的解决往往需要同ERP相关的幕础设施或其他应用系统各职能部门密切配合了决速解决。为达此目的，需要马上启动危机管理。危机管理的目的是以最快速度调动所需要的资源尽快解决事故，最大限度地降低事故对业务的影响，并和相关的业务部门及时和定时地通报事故对业务运作的影响和事故解决的进程，可能的话提供临时备案以使重要的业务运作能进行下去。
　　在这类危机管理中，ERP支持部门一般依然担当事故经理。事故经理需要其有非常有效的协调能力、沟通能力及快速决策能力，故而危机管理中的事故经理往往由ERP部门的相关主管或经理来担任，他们所要做的工作是:
　　1)紧急联系可能与此事故相关的各lT职能部门负责人组成危机处理小组，主持召开紧急会议讨论产生事故的可能原因，制定行动计划并马上付诸行动。
　　2)及时和定时地与相关的业务负责人及关键用户沟通事故对业务的影响和解决进程。
　　3)评估事故对ERP系统的影响，制定行动计划以便在事故解决后马上对系统进行处理，以最快速度恢复业务的正常运作。
　　为有效实施危机管理，事先建立一个具体的可执行的操作流程和与相关部门的联系方法是至关重要的，它能使事故经理在处理危机时根据流程作出快速有效的反应。
　　4 总结
　　在设计应用干ERP系统管理的事故管理流程时，应充分考虑ERP系统的特点和业务部门对ERP系统的要求，不能直接照搬应用于基础设施的流程。
　　应用于ERP系统管理的基于ITIL的事故管理流程的特点总结起来是:
　　1)支持流程要简练快捷;
　　2)充分重视和发挥关键用户的作用，关键用户和ERP功能支持组直接沟通;
　　3) ERP支持人员作为事故经理和用户保持单点联系;
　　4)由关键用户和IT支持人员共同决定事故的紧急性、影响度和优先级;
　　5)必须有良好的反应快捷的事故危机管理机制。
　　本文作者创新点:根据ERP系统的特点和业务对ERP系统的高度依赖性，提出一套基于ITIL.方法论但又适合ERP系统要求的事故管理流程，该流程提升了企业IT运营效率和客户对IT部门服务的满意度。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。