如何实施企业信息系统（上）（by AMT 曹伟）

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

如何实施企业信息系统（上）

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

by AMT 曹伟

一．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方案就不能适应，客户将感到很不满意。这个情况是在项目之初，没有确定需求，这需要客户书面申明必须在一定的时间阶段内保证该需求不变更，系统设计人员应与客户领导商定近阶段内客户在业务上或组织结构上的变化，便在系统设计时留有相应接口。

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

未完待续

浏览：如何实施企业信息系统（下）

作者申明：该文章仅授权予AMT(www.amteam.org)，其他网站或刊物不得转载，若有需求请联系AMT和作者。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友