如何实施企业信息系统

  －－C公司“微型”ERP系统项目总结

  by AMT 曹伟

  摘要：

  在实施项目几年来，我开始一直认为项目很难实施，可是随着对实施过程的总结，才发现原来别人天天在说的ERP项目很难实施，我常问自己为什么？我总结成三点六个字：过程、方法、决心。

  一．ERP的味道

  可以说是ASP（应用服务提供商），对实施成功的ERP有哪些认识，有一个众所周知的公式：

  ERP应用成功=有准备的企业+合适的软件+成功实施

  而三者之间，成功实施是保证ERP系统应用成功最重要的因素,而这个因素正式我们所欠缺的，我们一味强调的是软件的可适应性，当然这个强调也是很有意义的，如果适应性好的话，当然的问题就是在实施上有较为有利的条件。

  从2001年8月底，C公司体系开始我公司提供开发的“微型”ERP系统，在实施UTStarCom维修系统时，UT公司的IT部经理问题我：“你没有做过ERP，如何来描述它？”，我告诉他：“递推”。信息系统我认为没有大小，只有它到底关联企业什么业务，若仅有一项业务，那是局部信息系统，若有多项业务或企业的全部业务（也可能只有几项），那它就是ERP软件。ERP软件实施的目的是什么—整合，对企业全方位的整合，不能局限于业务流程，更重要是将要使用到该系统的人员的意识。

  C公司是一个销售型公司，那么这样的公司在对业务的需求上，除了行业内的“自需”东西以外，还有“共需”的东西。这些共需的东西就是ERP软件的精髓。

  “麻雀虽小，五脏俱全”，今天，我来解剖一个“麻雀”，通过这个解剖的步骤和大家一起认识“五脏”。

  首先“日参省乎己”，来剖析自己，感悟如下（从实施手册上摘抄下来）：

  项目实施，大多数是由软件产品供应商和咨询公司（我们的战略上的竞争对手）的顾问组成的实施团队来负责，当然，在C公司的体系中，就是我们在具体的实施。项目结束后，我们不会在该公司驻留，固然需要培训合适的人员。由于ERP系统不是交钥匙的工程，运营的事情主要有企业本身承担。如果企业在实施过程中，不注意有关信息的挖掘、分析并加以管理。那么，运营的过程将会不顺。对信息的挖掘是格外重要的，尤其是对我们软件开发这样的公司。

  在一段时间我们需要和系统实施公司保持较为亲密接触，以保证在系统基本完成的基础上，有一个略高于系统本身构架的客户需求，而这个需求对于软件开发商来说是至关重要的，为较为长期的服务提供一个基础信息平台。就C公司的系统这个基础信息平台并没有搭建，关键的问题在于没有他们公司的人员参与该项目中（但参与进来也是给我们制造麻烦），也没有一个人员跟随项目的实施，所以在项目结束的现在，其实施过程除了给我们本身带来经验外，其他的代价全是白费的。

  ERP系统的实施针对是业务骨干人员，并不是基层的秘书，实施的目的也是减轻基层人员的数量和劳作量，固然不可能是针对低层要求设计业务模式，但低层人员是该系统的操作者，在用户视图上一定需要符合低层人员的操作习惯。这个在软件的概念上是很清晰的，所以在程序的编制上也是很清晰的。业务流程是由业务骨干提供，程序表达的界面是需要符合操作人员的习惯。就实施过程而言，一般企业认为，这个是信息系统，应该由信息部门来陪同软件供应商协同解决，而他们的骨干还‘必须’忙于业务。是的，业务固然需要忙，但这个系统是为了业务而构架，他们应该抽空整理一下业务流程，并详细地和实施人员沟通，这样才能很好地解决实际问题，如果业务人员不参与系统流程的讨论，等系统构架完毕后，才发现不对，已是无法挽回（我幸运，这问题没有出现在我身上）。

  在现代的企业，之所以强调采用ERP等管理软件，有两方面原因，一个是大，一个是杂。其实原因之二来自原因之一。在市场经济的调节下，组织变动在公司中是司空见怪的，如果在项目过程中发生的话，其项目内容（人员、系统设置和数据）也必须跟随着变化，这个变化是很糟糕的。在C公司的实施过程中，这个变化是频繁的，所以程序结构和维护流程不停的变更，从而导致系统实施无期限。从这一点上，我们在C公司的实施过程上是失败的。

  别人云：不变的企业是死亡的企业，但是很多企业也是给不停的变折腾死的。ERP本身是灵活的（作者观点：其实对于软件来说也是灵活的，关于上述的软件的不停变更是在软件设计构架上的问题，这个问题有待解决，其解决方法很简单的），对于企业结构有适应的适应力，但这里并不等于说在项目中不应该控制企业的变动。这个问题需要分两方面来看，首先，ERP系统立意要高，要高到和公司组织结构规划一致（当然对于企业本身也应该考虑企业重组的问题），两个问题当一个问题来看；其次，就象人在适应社会的变化以前会经历襁褓期，但我们也该注意在ERP实施的襁褓期减少不必要的震荡，使项目成功完成。

  其实有一个问题，在客户看来我们是“拉雪撬的狗”，而不是“探索新领域的向导”，但这个观点恰恰和事实相反。如果思想上存在问题，那么就需要从思想来解决问题。

  对于用户，其关键用户和最终用户的培训是不同的，但先培训关键用户，再由关键用户去培训最终用户，这样是有好处的如：(1)语言上不存在障碍，同样一个流程或操作，最终用户一般更容易接受关键用户概念，而我们的概念往往是不能被最终用户直接接受的，这里面有行业术语上的障碍，在我们表达上基本上是计算机的术语，而用户所能接受的是他们行业上的术语。(2)更容易组织，由于我们是外部人事，对于他们我们基本上没有什么威慑力，如果有也仅仅是在技术上的敬佩，所以对于企业的协调能力或方式，不能见效，其内容也往往流于形式。(3)自然培养企业内部技术支持路径，而比直接询问我们有更好的效果，这样也会在我们的市场推广上有较为“阳光”的一面（这个问题我们已经有个好的例子，就是在向其他用户推广时采用用户本身直接介绍的方式）。同时其最终用户在询问关键用户问题时，自己也会很好的考虑（这个已经涉及到自己的利益）。(4)锻炼关键用户，让关键用户在培训别人上对本系统有认识上的提高。这个方面我们在C公司的系统上有涉及，而且在以后也需要更好的实施。

  如果把ERP系统设置比做树干，主数据就是枝叶。本来，在大型企业中像商品（但ERP系统中称为物料）等主数据的编码（C公司体系定义财务相关的编码）和管理可以作为一个项目来实施，但是由于ERP中提供了很好的主数据的整合工具，而且ERP中的主数据有专门的数据结构和逻辑关系，所以将主数据的整理工作直接作为ERP 的一部分对企业来说是很有好处的（针对如此直接的数据挖掘，我编写过一篇《企业实时数据挖掘》），但是对于软件供应商（我们）来说，主要负责是确定主数据的分类、字段选择、提供资料收集格式和帮助导入系统，而具体收集和整理工作由客户完成。在主数据的定义上还需考虑如何和以后的数据仓库或其他数据分析的应用。

  C公司项目中，更多的数据整理仅仅是流于形式，例如：商品的会计科目或其他的什么分类帐，这一点，我们没有完全进行系统处理。我一直有一个不良的感觉，好像在这一点，作为实施工程的人员似乎缺少100%的责任感，当然这个和项目的时间也有关系。要克服这样的不良的感觉，需要项目经理在项目实施前中和客户建立企业的下一阶段企业策略，这一项工作，我在AMT上《企业信息系统的实施时为何会惨遭失败》中的观点是让咨询公司来做。

  另一方面，在对C公司的解剖的过程中，数据的不完整性是在过程中忽略的，在前面阶段或后面的阶段，对数据的捕捉已经在变了，固然造成数据的不统一性。

  在理论方面，我们并不具备对客户旧系统的兼容，但C公司的旧系统也是我们做的，不过很简单，没有兼容的意义。所以我们仅仅负责将原始的数据整理成一个期初值，然后再导入新系统。但在其他的ERP项目的实施手记上经常看见，由于期初数据并能及时输入，导致业务凭证越来越多，日子一天天过，最后所有的数据白搭。

  究其上的所有的原因，是因为很多企业没有对帐的经验，特别是和ERP系统并列对帐，我在设计方案的时候，必须针对用户的对帐开发一些工具，在C公司系统上，这些帐务由我们来对，针对不同的数据我们也专门开发一些工具，但这样做法的弊病是他们现在的所有错误都还由我们完成，情况就不正常了。所以上面提到的培训关键用户就显得非常重要。

  针对上面的感受和开始的公式，我们一比较那个方面都有欠缺，所以还不好说我们是成功还是失败，从本质上将我们没有成功，但我们也没有失败。得到的是一系列很好经过检验的好的模式。

  现在感觉ERP的味道，我告诉大家，这个是苦涩的。但回头看看在实施手册的记录上文字，让人心累！！

  二．如何弥补我的工作

  作为系统设计者和项目经理，我首先对企业进行了一次调研，初步了解企业的业务和各部门的需求，然后有针对性地准备了一份调研报告，提出了企业在管理中存在的诸多问题，必须要借助ERP系统的实施进行一次管理改造；高层领导必须非常认可这份报告；紧接着，我们对整个企业高层领导和业务部门经理举办了一次ERP系统管理理念的培训。通过此次培训，高层领导认识到ERP是管理改造项目，离不开高层领导的支持；同时也对ERP系统也有了正确的预期，认识到ERP系统能够解决什么问题，不能解决什么问题。

  重新改组项目小组。重点是吸收了业务部门经理参与项目小组，并承担重要角色，IT部门仅起到支持作用。如果项目小组基本上以IT部门为主，业务部门参与太少，其公司员工对该项目会持怀疑态度，消极应付。

  经过进一步详细需求调研，确定企业上ERP系统的主要目标，从而也就确定了选择ERP系统的标准和量化指标体系。设置指标体系时不仅考虑了软件的需求满足程度，还考虑到软件的扩展性和ASP自身的发展等因素。

  我以下描述的问题都已经是“老生常谈”，这些问题在每个项目中都存在或多或少问题，正如一位资深的人士所说：“没有”。

  1．项目开始时，不可轻易承诺项目何时完成

  国内很多企业在实施ERP项目时，在项目启动后，甚至在项目还没有启动，就要求实施项目组提供一份详细实施计划，要求确定何时完成整个项目。特别是国内某些企业的ERP项目，往往需要某些机构的验收，这些验收单位一般事先规定了一个截止日期，要求ERP必须在该截止日期前完成。这个时候，项目经理面临压力——即需要给客户留下自信的形象，这种无形的压力驱使项目经理往往承诺客户提出的项目完成日期。

  然而，在项目刚启动，就承诺一个非常明确的项目完成日期是比较危险的，这是因为，一方面，项目刚启动时，项目的实施范围通常还比较模糊和抽象、不是很具体。只有等到需求调研以后项目实施范围才会逐步具体化，即使到这时，项目范围还存在随着项目进展发生改变的可能性。

  另一方面，如果对客户承诺了一个固定不变最终期限，如果在调研时客户发现需求和设想有很大不同，比最初项目评估时要复杂的多，因为完成日期已经无法更改，这样造成的后果是项目组成员需要投入更多的时间或者匆忙之下只能提交一份不令人满意的解决方案。

  因此，项目经理必须和客户沟通，使客户明白，项目完成日期的确定取决于两个因素：一是需求调研完成以后，双方共同确认的项目实施范围；二是要考虑到项目所需资源约束。这样如果以后项目范围明显地超过最初确定的范围，项目经理就需要和客户讨论，要么让客户缩小项目范围，要么延迟项目完成日期。

  一定需要认真调研，仔细评估，详细分析后给出一个合理的项目计划。

  2． 选择合适的成员和项目组结构

  如果实施任务非常紧急，项目经理应该在组建项目组时，考虑多配备经验比较丰富的成员。如果成员比较缺乏，应将项目实施完成延期到合适的时间，切不可随便用一些新手来代替。从项目一开始时，项目经理就必须严格控制项目质量，任何在质量上的妥协，都是项目后期出问题的潜在隐患。

  另外在选择成员时，不仅需要考虑成员以前的业绩、能力，还需要考虑成员的未来的潜力。近日，和朋友聊天，就项目组的组成结构等问题进行一系列的讨论，认为项目组成员若在10人之内，应采用扁平化的处理，若在10人之外，应该采用简单的组织结构，同时加强沟通。在选择项目组成员时应根据项目组的结构选择适合成员。

  3． 项目组所有成员明确的里程碑

  在ERP项目实施中，必须制定明确的里程碑，以及每个里程碑应取得的成果。项目经理在项目的开始，就需要让项目组所有成员知道各个阶段的里程碑和目标，以及进度的安排、资源的大体上的分配，就好让项目组的所有成员参与讨论，但项目经理应控制谈论的范围，需要避免在项目初期在实施上的分歧。

  大型ERP项目的实施往往时间很长，这样项目刚开始，项目组成员有一种错觉，认为时间还很充足。所以必须对里程碑进一步细分，制定短期的实施目标，让项目组成员时刻保持高效的工作状态，如果这些小的目标都能按时完成，那么整个项目按期完成就有了保证。

  ERP项目实施时间长，对顾问和客户来说，成功似乎遥遥无期。如果将目标进行分解，让顾问和客户都感觉到一段时间就实现了一个目标，可以激发项目团队和客户的积极性。

  4． 要经常性地交流与沟通，强调团队合作

  交流与沟通包括项目组内部的沟通和项目组和客户之间的交流。

  项目组成员之间要经常交流和分享各自成功的喜悦和失败的教训，我们常常说ERP项目组是一个团队，也就意味着团队成员之间必须要通力合作，才能保证项目成功。

  ERP项目实施团队中，每一个成员都要把项目成功看成头等大事，任何事情都需要在保证项目成功的前提下去做；

  在整个项目团队中，模块实施团队必须把自己负责模块的实施成功看作是整个项目成功的一部分。项目经理要时刻注意，防止出现侵蚀团队合作精神的苗头。

  同时，项目经理一定要向客户强调一点，那就是，ERP项目实施成功不是项目组一方努力就可以了，它必须要有客户的紧密合作。

  缺乏交流只会导致一些重复工作，减缓项目进展，甚至导致项目失败。

  5．计划安排要符合实际，留有余地

  在项目实施过程中，来自客户的压力，或者项目经理急于证明自己的能力，导致项目经理在安排计划时，过于紧凑，无法完成。

  不切实际的计划安排后果只能是挫伤项目成员和用户的积极性和信心。试想一下，如果项目经理在安排项目计划时，是基于非常乐观的假设前提，并对用户做出承诺。当客观情况稍有变化，项目就无法按时完成，后果就很难弥补了。

  所以项目经理必须注意，计划一定要切实可行，如果项目经理感到自己缺乏经验，应该虚心地向有经验的项目经理请教。这当中，有一点感触就是——计划一定要留有余地，以应付一些突发事件。俗话说，“计划没有变化快”。项目经理都有以下经验，无论计划做的多好，实际情况总是会脱离计划，只是改变程度不同而已。由于ERP实施时间长，会发生许多事先根本没有想到的突发事件。这样，即使其他一切事情都按事先安排进展，项目仍然有延期的可能。所以，安排计划时一定要留有余地，以应付突发事件。

  所以，我在安排项目计划在每一个里程碑，我将留有10%-20%时间做评估、修改，重新整理，保证在这一个阶段做到最优，同时根据评估的结果调整下一阶段。

  6． 严格控制项目范围

  在更坏的情况下，项目虽然在最终期限内完成，但解决的不令人满意，当企业的环境稍微发生变化（如组织机构调整、某些流程的改变），但项目组前期做出的ERP方案就不能适应，客户将感到很不满意。这个情况是在项目之初，没有确定需求，这需要客户书面申明必须在一定的时间阶段内保证该需求不变更，系统设计人员应与客户领导商定近阶段内客户在业务上或组织结构上的变化，便在系统设计时留有相应接口。

  一旦和客户确定了项目实施范围以后，如果客户提出某项新的需求，而项目需求又会显著地改变项目范围，项目经理就必须评估它给项目计划的影响。并和客户达成协议，如果要满足这项新需求，必须延长项目实施时间。如果项目经理对实施范围控制不力，接受客户提出的新需求，但没有改变项目完成日期。这会使项目组成员感到灰心，因为他们必须要在同样的时间内完成更多的工作，特别是如果最初的计划本来就很紧时，更是如此。

  三．培训工作

  高层领导管理理念的培训。

  这种培训就是我们在企业高层领导做的培训。培训目的是让他们形成共识，理解为什么ERP系统是管理改造项目，离不开高层领导的支持；另外一个目的就是让他们对ERP系统有一个正确的预期。如果，不对高层领导进行培训，他们对系统的认识不清，他们会认为系统不就是一个软件吗？没有必要投入那么多的钱。

  曾有过这样一个笑话，我们的客户给我们打电话，告诉我们他们将决定上一个全国分销系统，我们连夜针对客户特征编写应用方案（还连夜飞去），我们到北京和客户见面，进行演示，可客户对我们的方案没有兴趣，经过三个小时的争论，我们才发现，他要求的所谓的系统就是一个简单的软件，而这个软件我们即使报个“天价”，也不会超过2万（而我们认为最少100万）。

  我通过这样的一个故事，我意识到我在和用户谈系统前，先和他们谈理念、概念。

  对项目小组的培训。

  对项目小组的培训包括项目管理的培训、实施方法的培训、系统软件功能的培训。系统实施对企业来说也是一个大型项目，成功的系统实施离不开成功的项目管理，所以项目小组成员必须了解项目管理的一般概念和方法。

  对于实施者，就是我自己，和开发小组的沟通没有什么阻力，但和用户的沟通往往带有“有色眼睛”。为什么存在障碍？需要培训。需要对参与这个项目小组的客户人员进行培训，在实施过程上保持一致性。

  对最终用户软件操作的培训。

  对最终用户的培训就是用户知道怎么操作软件，是企业最能够接受的。我还是建议我在上面描述的培训方式，主要培训关键用户，培训那么几个人后，在协调关键用户培训最终用户。

  我记得我在1999年，还在南京力导电子系统研究所（其实是一家民营公司，那时我的专业呀）做售后工程时，我有一个绝妙的培训方式：因为我们的客户是市县电力部门，所以客户是国有体制，如果工程我自己来做，很累，而我完成后，什么样的小问题都会打电话找我，那个时候，我基本一个人负责华东地区，占公司60%以上的业务，那就是我有72般变化也无济于事。我决定我不做系统实施，我在客户处，先和局长等领导聊天，凭我在电力上的知识很快和局长聊的很投机，顺势将工程实施的问题向局长建议，当然，他们自己来做时能更好使用这个系统（但我的目的不是这个），局长听之有理时，我会建议让他们人员来做，他们的人员很愿意在局长等领导面前表现，他很高兴（有升职的机会），我很高兴（我可以不干活，而且以后维护问题很少），局长很高兴（有人陪他聊天，当然还有其他好处）。三方都高兴，何乐而不为呢，有些时候，我会抽时间给局长面子，在局里开一周或半周的自动化培训班（局长、主任也有业绩吗）。如果局长等领导不理我，我会找其他方式的。

  当然，对用户的培训，主要是要抓住关键的东西，保证项目投运后，软件提供商尽量做到免维护。

  ?

  对流程和数据分析的培训。

  ERP实施中技术虽然很重要，工作量也很大，但并不是最难的；最难的是ERP实施必须要对管理做很大改变，即进行业务流程重组。这样，ERP实施完成后，员工都面临着全新的业务流程。对流程的培训也就意义重大了。员工的操作我还是建议最好让关键用户去培训，当然我需要提供操作手册或用户手册之类的东西，这样保证即使是重组的业务也好让最终用户理解。

  ERP系统正常运行后，会有很多有用的数据。如果这些数据放在那儿不去利用，就不会很好地发挥ERP系统的作用。所以必须教会企业如何去分析数据，为企业决策提供依据。

  其他

  除了上述的培训外，还有其他的培训，各个项目根据需要制定相应培训计划或培训方式，保证项目在约束条件内顺利实施。

  四．C 公司“微型”ERP项目实施过程

  1．确定用户的最终需求

  在开始我们认为具体的业务流程我们已经很熟悉了，固然没有什么具体协商的。但是到了最后使用的时候，我们就发现我们还是对其详细操作没有搞清楚，我知道的业务流程仅仅是一个大体上的概念，对于细节的业务我并不清楚，这个问题是我后来在项目延期的主要因素。

  确定用户的最终的需求，根据用户的需求编制一定的界面，然后根据编制的界面和用户进行核对，以保证我们表达的和用户需求的相一致。如果不一致，重新修改我们的界面。

  根据和用户讨论关于操作问题，这个阶段就是搞清楚用户的视图，让最终用户直接参与项目的开发，当然他们的作用是提供一些参考改进的意见，这些意见是针对最终用户的操作，目的是让操作更加贴近用户。

  （期间的艰辛只有我自己知道！）

  我总结了这个经验是：强调项目组成员（包括我自己）做到“不能有‘我以为’的思想”，一旦有如此思想，项目需求一定欠缺，因为客户---所有的客户---也是在‘我以为’。项目做要想做到抓住所有需求，一定要抛开自己的设想。

  所以，任何一个项目组成员，我第一句话就告诉他，不要有“我以为”的想法。

  2、 制订模块实施上线计划

  当系统实施进入上线阶段，一方面，很多业务部门将切实参与到系统实施工作中来；一方面，上线阶段，工作量大，要准备的基础数据多。所以必须做好切实可行的上线计划，保证上线工作有序进行。在制订计划时，要注意：

  1．计划要做到天，要详细规定每天应完成哪些工作。

  2．计划一定要分到责任人，要确定哪些工作是由项目组做的，哪些工作是由客户做的，并要让具体执行人清楚地知道计划。

  3．计划一定要规定截止时间，如规定在某月某日之前要准备好某项基础数据。

  4．制订计划时，要考虑资源（人力、时间）制约。如财务部每月月底要准备财务结算，不能抽过多时间。

  5．制订计划，一定要留有余地。根据我们的经验，在上线阶段会遇到各种事先没有预计到的问题，所以，过于紧凑的计划往往不能按期完成。

  做到如上几条，很难。但有如此设想的人，大有人在，对于项目经理经验和能力并列第一。参照我在第二条---如何弥补我的工作---中的几条描述，兴许会给各个项目经理一些实质的东西。

  3、准备基础数据

  在实施演义之一，我们说过，ERP系统成功三大因素依次为：人、数据、技术。可见基础数据准备的重要性，该系统中数据可分为两种：

  一种称为静态数据，所谓静态数据一般不随时间不同而改变，如：①商品条目文件②商品清单文件③各部门、各种资源④供应商基础资料⑤客户基础资料⑥会计科目等等。因为静态数据一般比较稳定，可以提前准备。另一种称为动态数据，动态数据一般随时间不同而改变，如：①库存余额，②总帐余额，③应收帐款余额，④应付帐款余额，⑤未结销售订单，⑥未结采购订单等等。这些数据要在各模块上线切换点的数据为准。比如，计划7月份总帐模块上线，一般以6月25日（这个是C公司的会计期间）总帐余额为准。

  在准备数据之前，成员要准备一份“数据准备文档”，在该文档中要明确如下内容：

  1.数据准备时间，范围。即何时完成，准备何时的数据，准备哪些数据。

  2.明确双方责任。我们一般要求客户来准备基础数据，并保证数据的完整性、正确性（实际也只有客户自己才能做完后，才知道数据的真确与否，一定要盯牢客户完成数据的测试）；项目组只提供数据准备的要求、格式。

  3.数据准备的要求。客户必须按照项目组要求的格式来准备，这一点非常重要，很有好处：

  （1）可以保证数据的完整一致。比如说，要准备供应商资料，我们在Excel中准备好空白如下表格。针对这个信息我们提供的一个更加详细的说明方式，让其自由填写。但以上表格中的数据是必须填写的。这样每个准备供应商信息的人，都知道供应商资料应该包括：供应商名称、编号、地址、税号/帐号、联系人。

  （2）方便核对数据。一旦在Excel中准备好数据，并核对无误后，就需要输入系统，输完以后，再用系统生成并打印报表（但我们没有这样做，我们自己准备一个数据库，在浏览器的界面，让客户自己直接在浏览器的界面填写，然后提交到数据，这样就减少了打印重新填写或导入的步骤，比如，对上述供应商资料，我们可以从系统输出一份报表，去和原始的数据核对，看看在输入过程中是否出错即可）。

  （3）如果基础数据量很大，一般就需要开发专门的数据转换程序，这样更需要按一定格式准备数据，否则，数据转换程序不会正常工作。如果企业本身没有其他系统（现在一般企业都没有），即可让其直接进行输入。

  在实际工作，很多客户一开始感到不理解，认为没有必要一定按照某种格式准备，作为成员一定要和客户沟通，解释重要性。

  4、培训最终用户

  上线过程中，有很多数据要输入系统，而且一旦上线后，最终用户就需要天天和系统打交道。为保证每个用户都能够熟练地使用系统，培训就显得很重要，简单介绍如下：

  1．让客户方项目组成员来准备培训教材，我（项目经理）提供指导。在系统实施项目组中，客户方有专门的模块负责人，也即我们上面所说的关键用户，他们因为很多时间和我一起工作，而且已经接受过我的培训，有能力准备培训教材。同时，系统上线以后，模块负责人作用很大，需要给他们一定压力来尽快熟练软件。

  2．我（项目经理）负责培训关键用户，让关键用户自己来负责培训最终用户。

  3．最终用户培训工作要经常进行。特别是如果客户原来计算机基础不是很好，一定要多做培训。这一点大家的感觉几乎相同，目前国内的公司中的最终用户一般的学历不高，而且对新鲜事物没有太大的兴趣，固然计算机水平都不高。

  4．培训要有一定的奖惩措施。为了提高培训质量，客户应该制订一定的措施，如规定，在经过一定时间培训后，要进行考试。考试不合格，进行补考，补考不合格，可以采取一定惩罚，以激励最终用户学习的积极性。

  虽然，第四看上去比较古老，在实际应用中非常有用。

  5、系统设置和数据初始化

  设置是系统实施中一个专门术语，其含义简单地讲，就是按照企业的实际情况和需求，配置系统参数，把一个通用的系统变成适合企业需要的软件系统。比如，对总帐模块上线，以下工作就属于设置：

  按企业需要设置会计科目结构，币种，会计日历，最终形成企业的会计帐套。

  按企业需要设置凭证的分类和编号规则。

  按企业需要设置凭证的审批方法。

  设置之前，需要准备一份“设置文档”。设置文档主要内容是设置的详细步骤，每一步是如何做的。设置文档是系统实施中一份关键文档，必须要完成，有以下作用：

  1．确保设置正确。如果没有一份书面文档，一面想一面设置，容易出错。

  2．更正有依据。设置完成后，万一出现问题（系统出错、或有人更改了设置），可以查看设置文档，很快进行修改。

  3．对客户来说，文档是知识的积累和转移。由于C公司是一家集团公司，有许多类似的下属子公司。在系统实施中，一般的模式是先以1-2家子公司做试点，试点成功后再推广。有了设置文档，推广工作就可以节约很多时间。

  一旦产品设置完成后，基础数据也准备好的话，下面的工作就是把基础数据导入系统。数据转换需要事先制订转换策略，确定是手工输入、还是用程序进行转换。一般原则是，如果数据量不大，可以采用手工输入的方法，否则需要考虑用程序来进行数据转换。

  基础数据导入系统之后，下面工作就是要核对数据，核对方法是从系统把数据以各种方式输出，和输入的数据进行核对。

  6、确保新系统正常运行

  上述工作均完成后，我们的系统就是要正式运行了（激动人心，顺势鼓励一下员工）。

  1． 验证设置是否正确。比如总帐模块，各种基础数据输入后，经检查，均正确无误，但系统生成财务报表就是不正确。这种情况下，我们就需要检查是否是设置问题。诸如此类的问题很多，需要一一验证。

  2． 制订各种业务规则。上了系统之后，许多新的业务流程和企业原有的业务流程不同，而最终用户往往习惯了以前的做法，短期内可能不适应。为了确保系统真正用起来，必须做好以下几点：

  （1）做好培训工作。培训系统的操作和系统的业务流程。

  （2）制订详细的业务规则，规定企业各种业务在系统中是如何处理的。并让每位相关的最终用户知道、理解。

  （3） 制订必要的制度，确保按规定操作，特别是在使用系统初期，完善制度尤为重要。

  五．总结

  每次写东西总不忘记写小结，可能领导要求写小结太多了，所以形成一种习惯了。

  C公司的项目实施已经快两年了，最近由于AMT网站给我很多的机会和鼓励，我决定写我最初的实施的那个项目，发现问题、解决问题、总结提高。

  该项目不算ERP，但我文章之处提出的，实施任何项目都一样，那就是“递推”。这种迭代式的实施项目方式，可参见我在AMT的文章《管理之道》。

  全文完