陈  晖 （1969-）：女，湖南人，硕士，研究方向为管理信息系统、智能控制、最优控制等

　　摘要：基于ITIL的IT服务管理在IT基础设施和ERP应用系统的实践是有所区别的。本文就业务运作对ERP系统的要求，结合ITIL在跨国性公司中的应用实践，在服务支持部分分析了IT服务管理在ERP系统中的应用特点，并提出了相应的解决方案。

　　关键词：ITIL；IT服务管理；服务支持；事故管理；变更和发布管理；ERP应用系统

　　Abstract: The ITIL based IT service management has different practices in IT Infrastructure support and ERP application support. This paper analyzes the characteristics of IT service management in ERP system based on the business requirement of ERP system and the practices in international companies, the related solutions are provided as well. The scope is limited in service support only.

　　Key words: ITIL；IT service management；service support；incident management；change management；release management；ERP application system

　　1 基于ITIL的IT服务管理简述

　　二十世纪八十年代末形成的IT Infrastructure Library (信息技术基础架构库, 简称ITIL )已经在全世界成为事实上的IT服务管理的最佳实践和标准。它是一套针对各行业的IT系统服务管理标准库，提供了一种流程处理的IT运营方案。基于ITIL的IT服务管理以流程为导向、以客户服务为中心，它通过整合IT服务与公司业务流程，提升了企业IT运营效率和客户对IT部门服务的满意度。

　　基于ITIL的IT服务管理（IT Service Management ，简称ITSM）作为一种新的IT管理模式, 在欧洲和北美等国家和地区得到了广泛的应用，近年来在我国也得到了越来越多的关注和应用。

　　提到基于ITIL的IT服务管理，人们更多地把它和IT 服务台（Service Desk）或IT呼叫中心联系在一起，通过IT服务台向用户提供IT基础设施的服务，例如PC 维护、网络、通讯、服务器、操作系统等方面的IT 服务。

　　事实上，基于ITIL 的IT服务管理在大型企业的ERP系统中也得到了广泛的应用，但在不少企业，甚至包括一些大型跨国性企业，由于IT服务管理的实施往往先从IT基础设施着手，然后再推广到ERP应用系统中去，使得IT服务管理流程带上了基础设施的烙印，或多或少地忽略了ERP系统的特点，从而对ERP系统的IT服务支持的效率产生影响，降低了用户满意度。

　　ITIL服务管理主要由服务支持（Service Support）和服务交付（Service Delivery）组成，这两者是整个ITIL框架的核心。ITIL服务支持主要论述客户和用户如何获得恰当的服务来支持他们的活动和业务，以及这些服务怎样得到支持。它主要由下列模块组成：服务台(Service Desk)，事故管理(Incident Management)，问题管理(Problem Management)，配置管理(Configuration Management)，变更管理(Change Management)和发布管理(Release Management)。

　　本文针对ERP应用系统的特点和相关业务对ERP系统要求的特殊性，根据大型跨国公司ERP服务部门的IT服务管理的经验和实践，就服务支持部分谈谈IT服务管理在ERP系统中的应用特点。

　　为叙述方便，文中将用到如下ITIL和业界通用术语：

　　(1) 一般用户(End User)：运用ERP系统进行业务操作的普通业务用户。

　　(2) 关键用户(Key User)：对所分担的业务有较深的专业知识和业务能力的用户。这类用户对ERP操作比较娴熟，既能解决和业务相关的问题，也能在授权范围内解决一般用户碰到的ERP应用问题，故而在一定程度上减轻了IT部门的支持工作。

　　
　　(3)事故单（Incident Ticket）： 由关键用户通过IT服务管理系统提出的事故解决请求记录。

　　2 IT服务台和事故管理在ERP系统中的应用特点

　　ERP系统从广义上来说，它涵盖了一个企业的整个运作周期，包括产品或服务需求预测、供应计划、采购、生产、成品管理、销售、物流、财务、库存管理、仓储管理、业务数据分析和决策支持、客户关系管理、供应商关系管理、人力资源管理等业务领域。复杂而多变的业务运作，大量的来自各业务部门的ERP用户，复杂而全面的ERP应用系统，决定了ERP系统的IT服务管理在流程上具有区别于基础设施IT服务管理的特点，具体体现在IT服务台和事故管理中的特点有：

　　（1）事故或问题的紧迫性和影响度需要IT支持部门作出快速反应。ERP系统中产生的事故或问题的紧迫性及影响度基本上是由相关业务的紧迫性和重要性决定的。有些事故或问题会直接影响业务运作，或影响公司的对外服务水平，或有法律上的风险。例如，对客户承诺的送货时间，价格主数据有误，ERP系统宕机等等，这些事故或问题需要IT支持部门马上做出支持，以便最大限度地降低对业务运作的影响。

　　（2）ERP系统事故或问题的解决需要和业务人员密切互动。ERP系统的IT服务支持和具体的业务流程及业务人员密切相关，同样的业务流程可以产生不同的问题，ERP IT支持人员需要和提交事故/问题的用户保持较多的沟通以便明确事故和问题所在，测试和确认解决方案。

　　ERP系统IT服务管理的这些特点决定了不能简单照搬基于基础设施的IT服务流程和方案，必须基于这些特点对IT服务流程进行相应的调整和完善。需要完善的地方是：

　　（1）对事故的第一反应必须快速有效，尤其是一些对业务运作产生大的影响的事故。有些事故也许只影响一个用户的系统操作，但所影响的业务可能是重要和紧急的。

　　（2）在第一时间和用户（即事故的提出者）沟通的支持人员必须具有ERP某个功能模块的系统经验和业务知识，所以必须减少从用户到相关ERP支持人员的中间环节。

　　在一般的IT服务管理流程中，服务台和事故管理是IT服务管理中最广泛运用的一个功能。服务台是直接面对用户的单一联系点，所有IT相关的服务请求均通过服务台进行记录、处理、回复或转发到相关的二线IT支持部门进行处理。

　　但在ERP系统支持方面，这样的传统架构和流程却往往会导致服务响应和解决的延迟，从而可能导致业务流程的延迟或中断，对业务产生负面影响。

　　其原因正是由ERP应用系统的特点引起的。一般来说在服务台工作的IT支持人员更多的偏向于IT基础设施方面的支持，他们往往能对PC，Windows Office应用软件，办公设施等进行有效的支持，但对ERP系统一般缺乏了解，只能做很简单的处理，例如重置用户密码等，对涉及业务流程的问题一般无法处理，更谈不上进行有效的支持了。这是由ERP系统的复杂性决定的，无法要求在服务台的一线支持人员是万能的，实际上也不可能做到。他们所能做的只是：①根据用户的电话述说或电子邮件在IT服务系统中开出事故单（Incident Ticket）。②根据记录来判断问题是否属于ERP系统。③转发事故单到ERP二线支持部门。

　　而在事实上，由于大型主流ERP系统涵盖了整个公司所有或大部分的业务运作，所以二线ERP系统的支持部门一般也按业务分成多个功能支持组，譬如财务组，销售分销组等，要服务台的支持人员准确地了解并把用户的需求或问题转发到具体的ERP功能支持组是有一定困难的。所以在现实中有些以这种IT服务流程模式运作的公司不得不在ERP二线支持中再设一个ERP服务台，这个ERP服务台对ERP各个模块有一般的了解，其责任是：①解决一些常见的简单的ERP事故，②准确地把和ERP相关的事故转发到相关的功能支持组去。这套流程如图1所示。

图1一般IT服务管理在ERP事故处理中的流程

　　这种运作模式带来两个弊端：①延长了事故的第一响应时间和解决时间，从而影响服务级别协议（Service Level Alignment，简称SLA）。②导致机构设置的重复，服务台和二线ERP服务台的职能从ERP应用系统的角度来说是重叠的。

　　为消除这两个弊端，提高IT服务的运作效率，提高客户满意度，在不少大型公司中，往往对ERP支持的流程做出一些改进，一般有两种改进方法：

　　方法1：把二线ERP服务台和二线ERP功能支持组合二为一，同时设立关键用户，普通用户向关键用户联系解决ERP事故，关键用户解决不了的则直接在IT服务管理系统中登记一个事故单，并把它指派给二线ERP功能支持组去解决。当然普通用户依然直接联系服务台解决非ERP相关的事故。其流程参见图2（方法1）。

　　方法2：另一种方法是成立ERP服务台，并同样设立关键用户。其流程是从普通用户到关键用户，再到ERP服务台，然后到ERP功能模块支持组。其大致流程见图2（方法2）。

图2 完善后的IT服务管理在ERP事故处理中的流程

　　这两种方法的共同点是由关键用户判断所发生的事故是否属于ERP范畴，这一点对关键用户来说是比较容易判断的，即便偶尔有误判，ERP支持人员也可以帮助分发到相关部门或请关键用户联系IT服务台去分发。

　　要注意的是关键用户除紧急状况外均不得直接联系ERP功能模块支持组的某个成员，而应该在IT服务管理系统中登记一个事故单，然后把它指派给某个ERP功能支持组（方法1），或指派给ERP服务台（方法2）。

　　相对而言，笔者更赞同方法1，因为它更高效。

　　3 配置管理在ERP系统中的应用特点

　　配置管理是实施基于ITIL的服务管理的一大难点。在配置管理中，最基本的信息单元是配置项（Configuration Items，简称CI），所有软件、硬件和各种文档，比如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等都可以被称为配置项。这些信息不仅包括基础设施中某个特定的配置项的详细资料，还包括这些配置项与其他配置项之间的相互关系方面的信息。配置管理是进行有效的事故管理、问题管理、变更管理和发布管理的基础。

　　在基础设施相关的配置管理中，搜集所有硬件（包括数量，位置及购买价格等）及相互关系方面的信息是一个浩大的工作。所以在实践中，基础设施的配置管理是不尽如人意的。

　　而对于ERP系统来说，配置管理就相对容易得多。ERP系统是一个大型计算机软件应用系统，例如SAP系统或Oracle系统，与之相关的服务器、操作系统和网络等一般归入基础设施方面，因此ERP系统是一个“虚拟”系统，只需考虑它的业务功能模块即可，下面是一个例子。

　　在该例中，ERP系统分为销售与分销(SD)、物料管理（MM）、 生产（PP）、 财务(FICO)、 计划（APO）、客户关系管理(CRM)、供应商关系管理(SRM)、人力资源管理(HR)、业务数据分析和决策支持(BW)等业务模块。在每个模块下，又可以分为若干子模块。以业务运作在各公司大致相似的财务模块为例，它又可分为总账(GL)、应付帐（AP）、应收帐（AR）、 固定资产（AM）、 资金管理（Treasury）、成本中心（Cost Center)、利润中心（Profit center）、接口（Interface）等等, 可以把配置项定义到子模块这个层次上, 其子模块和模块间的关系如图3所示。
 

图3 ERP系统配置项与功能模块及子模块的关系

　　这样ERP-FICO-GL、ERP-FICO-AR、ERP-FICO-AM……等等便是一个配置项。

　　另外，作为跨国公司，ERP支持一般按美洲（AM），欧洲（EU）和亚太（AP）三大地区来运作，构成5*24小时甚至7*24小时服务。因此为了区分问题发生在哪个地区，可以在配置项中加上地区，比如AP-ERP-FICO-GL、 EU-ERP-FICO-AR等。

　　在对一个事故或问题匹配配置项时，很容易通过事故或问题发生在哪个子模块和哪个地区而快速找到配置项，从而为事故或问题的分析和报告以及系统的完善提供依据。

　　4 变更管理和发布管理在ERP系统中的应用特点

　　在大型ERP系统中，一般每隔一定周期要对ERP系统作一次系统发布，系统发布的目的是：①解决ERP运行中发现的问题；②根据业务需求增加新的功能或对已有的功能进行完善，包括在某个国家或地区实施ERP系统。这些变更是定期发布而不是随时发布的，比如每月一次，否则会影响ERP系统的稳定运行，从而影响业务的运作。当然，为紧急事故或问题开发的变更，则需通过紧急变更和发布流程进行管理。但即便是紧急变更，也需要经过类似但快速的流程。

　　在IT服务管理实践中，变更管理往往和发布管理融合在一起，对ERP系统管理来说同样如此。一般大型跨国公司的ERP系统是一个复杂庞大、彼此紧密联系并相互作用的系统，某一功能模块的改变可能影响其它模块的正常运作，或者某一国家要求的特殊功能变更和完善可能对另一国家的业务带来负面影响。

　　因此在ERP变更和发布管理中，需要做彻底的测试，以保证：①所开发的变更符合业务需求或解决存在的问题；②对其它模块功能不会产生负面影响；③其它国家或地区能正常使用同一功能模块，也即该变更对不需要此变更的组织来说是透明的。在测试中若这三项要求中的任何一项产生事故，并且不能在计划的发布窗口前解决事故，则该变更不能发布，需要重新完善。

　　由于ERP系统和业务的紧密结合，ERP的变更管理和发布管理需要业务部门的深度介入，例如需要业务部门在提出业务需求，测试解决方案，用户培训等环节发挥重要作用。而不象在基础设施中那样大多由IT部门独立完成变更。 同时任何的变更在发布前，新开发或完善的功能需要由IT变更实施者对ERP IT支持人员进行技术和操作方面的知识交接，对业务部门的用户进行操作方面的培训。

　　这里只讨论变更和发布管理在ERP系统中的应用特点，所以许多与基础设施的变更管理类似的环节，例如变更的登记、评审、确定优先级、发布政策和计划等等，在此不作论及。

　　一般ERP的变更发布流程根据测试变更的主体的不同有两种：

　　方法1：由ERP IT支持人员和关键用户先后测试ERP系统，并最终由关键用户确认：①新的变更是否符合业务需求，②变更是否给系统本模块功能或其它模块功能带来问题。该方法的主要流程如图4所示。

图4 变更发布流程—由关键用户最终测试和确认变更

　　方法2 ：由ERP IT支持人员测试ERP系统，并最终由ERP IT支持人员确认，主要流程见图5。

图5 变更发布流程—由ERP 支持人员最终测试和确认变更

　　最终负责确认变更通过测试与否的部门（如方法1中的关键用户和方法2中的ERP IT支持人员）所作的测试内容应包括：①对变更本身的单位测试（Unit Test），这主要由提出此变更的所在国家或地区的业务部门去测试；②对重要业务流程的测试 - 称之为回归测试（Regression Test）。回归测试是一种基于重要流程的测试，它需要由所有用到该流程的国家或地区去测试。任何一个国家或地区在回归测试中发现的问题，必须在发布前得到解决，否则某个相关的变更必须推迟发布。回归测试的方法是对一个完整的业务流程作一个全面的测试，而不论变更中有没有涉及到该业务流程，确保任何的变更不会对其他重要的流程产生影响。

　　需要指出的是，在开发部门做变更开发的环节中，单位测试环节不仅包括了IT开发人员作面向系统的单位测试，也包括了参与开发的业务人员做的面向业务的用户接受测试（User Acceptance Test, 简称UAT），只是在这个环节作测试的往往不是关键用户，而是和IT搭档的业务专家（Business Expert）。所以无论方法1或方法2，均有业务人员参与测试。

　　不同的测试方法适用于不同的行业，方法1一般用在高度依赖ERP系统的行业，例如快销品行业，这种行业的运作对时效性要求极高，无时无刻不用到ERP系统，尤其是销售、物流和仓储等和客户服务相关的环节，必须时刻保证ERP系统的稳定性和可用性。当然代价是成本比较高。

　　实际上，在对ERP依赖度比较大并且IT管理比较严谨的公司，在变更发布完成后投入正常操作前，还需要在生产环境中作两个测试：①ERP IT支持人员对发布后的ERP系统检查重要的系统配置和与其它系统的接口，可能的话需要做一些对业务没有影响的操作；②关键用户需要对一些重要的流程作一遍实际操作，故需要保留一些真实的业务数据供这时使用。作这两个测试目的是确保变更后的ERP系统能在投入使用后正常运作，避免事故或使事故的发生率和对业务的影响最小化。

　　方法2则适用于对业务运作的时效性要求较低的行业，其业务对时间的冗余度相对大一些，一般情况下容许ERP支持人员花费相对多一点的时间解决事故/问题。

　　5 问题管理在ERP系统中的应用

　　问题是指一个或一类事故重复发生时所对应的根本原因。问题管理的目标是消除事故背后的根本原因，从而使同类事故不再发生。

　　从ERP系统来说，问题的根本原因可能是：①应用程序的逻辑错误；②应用功能模块程序没有考虑到所有或特殊的业务场景；③支持ERP系统的IT基础设施存在问题。

　　一般来说，一旦事故被确认为问题，则该事故单可以被关掉，同时在IT服务管理系统中登记相应的问题，并把该问题和事故联系在一起，从问题管理的流程来说，ERP系统和其它系统是类似的，这里就不再详述。

　　6 结束语

　　本文讨论了ITIL的服务支持（Service Support）在ERP系统中服务管理流程的应用特点。这些特点是由业务部门运作对ERP系统的要求决定的。在ERP领域实施IT服务管理系统和支持流程时，必须考虑到业务运作的特点和对ERP系统的依赖程度，从而制定出适合业务对ERP系统需求的支持流程，尤其在事故管理、变更发布环节。

　　参考文献

    [1] Berkhout M, Harrow R, Johnson B, etc. Best Practice for Service Support[M]. London: The Stationery Office Limited, 2000.

    [2] Bartlett J, Hinley D, Johnson B, etc. Best Practice for Service Delivery[M]. London: The Stationery Office
Limited, 2000.

    [3] Jan van Bon主编,章斌翻译.  IT服务管理—基于ITIL的全球最佳实践[M]. 北京: 清华大学出版社,2006.

    [4] 左天祖,刘伟. 中国IT服务管理指南[M]. 北京：北京大学出版社, 2004.