谈起ERP项目，必谈到风险与失败，大概是出自妇孺皆知的“找死等死说”或者是某媒体不负责任的“ERP成功率为零”罢。但是，知识经济的今天，效率和成本已经成为公司生存和发展的根本要素，企业管理的信息化已经成为现代企业的必然选择。ERP无法躲避，只能去探讨如何减低风险，提高项目的应用效果。
   
    1. 来自人的风险的规避
    　一个被叫得很熟的口号是“一把手工程”，足以见企业一把手在项目中的重要意义。但一把手在项目中扮演怎样的角色，参与多深，对项目的成败影响很大。实践证明，一把手不可能有充足的精力参与到项目中去，他只能扮演项目的战略决策者，仲裁人和激励者，项目的真正领导者和推动者应该是紧跟在他后面的经他充分授权的一个人。如果过分地强调一把手在项目中的重要性，一把手又真正地要身先士卒，如果项目中的很多事都要一把手来参与决定的话，一把手很可能成为项目进程中的“瓶颈”，很多任务会因为他的时间的冲突而进展不下去。一把手是一个企业的灵魂，但凡涉及到企业伤筋动骨的项目都要他来拍板，都是所谓的“一把手工程”。所以对“一把手工程”的理解不能片面，过于片面会走向另外一个极端。

  　  项目经理是项目的具体领导者和执行者，通常用户方和咨询服务商各安排一个项目经理。项目经理的称职与否对项目影响很大。项目经理在项目中主要责任是项目的控制、协调和指挥。沟通能力、控制能力对项目经理来讲是至关重要的两项能力。责任心、敬业精神是项目经理必须具备的品格，兼听并蓄是项目经理必须遵从的工作方式。项目经理在项目中处于承上启下的位置。承上，接企业的最高管理者，要充分理解企业最高管理者对企业发展的战略，启下，要把企业领导者和项目委员会的意图完整地传导给项目的执行者。项目经理要有很强的执行力，切忌老好人来做项目经理，也切忌项目经理成为“海绵垫”，如果项目中的很多矛盾到项目经理这里都缓解了，但不能从根本上解决，就为项目的崩溃留下了蚁穴。

　    每在项目启动前，用户方组建项目小组都是一件很难的事，难的是如何把人抽出来，的确，今天的企业都是一个萝卜一个坑，没有闲人。但所有经历过的项目都告诉我们，ERP项目是一个永续的工程，绝非一劳永逸的阶段性工作，所以一定要在项目进行过程中培养出企业自己的能保证后期应用推广和深入应用的人才。作为用户方项目组的成员，我们通常叫“关键用户（keyuser）”，来自于企业的业务骨干，和技术顾干，需要能够“讲出来，做下去”。参与项目的业务骨干需要能把目前的业务流程和业务需求讲清楚，能够理解供应链的管理思想，能有企业全局的观念，有一定的电脑应用经验，积极参与项目小组的方案讨论，最终有能力向业务部门解释项目小组设计的方案，有能力推动项目的有效执行。参与项目的技术骨干要有能力学会系统应用的日常维护和后续的外围开发。用户在组建项目组的时候，既要考虑到参与项目的员工的稳定性，也要考虑到项目组成员的学习能力和创新能力。

   　 更准确地讲，ERP项目不仅是一个“一把手工程”，更是一个全员项目。几乎关系到企业中的每一个员工。要涉及到观念的转变，工作方式的转变，流程的转变。在项目的实施与推广过程中，参与项目的绝不仅仅是项目小组的几个人，而会是更多的人。他们需要接受理念的培训，流程的培训，系统应用的培训，他们还要参与整理数据。在项目中要调动每一个参与者的积极性，不妨参照马斯洛的需求模型（生理—安全—社会性—被尊重—自我实现），循循利诱，让每个人都发自内心积极地参与工作，让他们能感到项目推广过程中给他们自身带来的实惠，譬如工作能力的方面，事业发展的方面，企业发展后他们的个人收入方面等等。简单的说教和施压往往适得其反，表面文章做好了，但实际应用的时候就掉链子，在数据整理和上线前培训往往会暴露问题。

    　外部顾问的问题也是一个关键风险所在，也是企业最关心的问题和难于回避的问题。在选型和选顾问公司的时候，用户方永远处于信息不对称的弱势那一方，即使选型过程拖得很长也难得要领，虽然在这个阶段接触很多供应商，但公说公有理，婆说婆有理，得到的信息越多，越是难以决策。我个人认为，产品方案的决策倒是简单一些，从产品提供商的实力、发展和行业应用与产品说明可以有一个简单客观的选择。产品是相对静态的，在实施过程中变数不大。但实施的质量更多来自于直接提供服务的顾问。对顾问公司的考察包括公司本身和项目顾问两个方面。顾问公司是一个典型的知识密集型组织，它的管理不同于传统的制造型组织。决定顾问公司的稳定性主要取决于两个方面，一个在现金流，一个在员工对组织的认同度，即企业文化。从顾问公司的人员规模和正在服务的项目规模可以大概考察到顾问公司的现金流是否正常，从与顾问公司销售、顾问和高层的反复接触，可以感觉到组织是否有一致的愿景。从顾问公司项目的管理方式，知识管理体系可以看到这家公司是在谋取长远发展还是追求短期利益。在参观样板案例的时候邀见相关顾问可以了解顾问的稳定性。顾问个人的考察，应着重于行业经验和项目管理经验，要沟通顺畅、思路清晰、有组织能力、有执行力、有说服力。
   
    2. 来自流程的风险和规避
    　必须要认识到，ERP是一个管理模式的概念，而不是一个软件的名字。引进ERP的时候必须对管理模式的转变做好准备。新瓶装旧酒，换汤不换药的做法都会对ERP的应用效果大打折扣。

    　早几年，提到ERP，必谈BPR（业务流程再造，或叫业务流程重组）。但由于再造的难度大和失败的案例多，以后就有人不提BPR了，改提BPI（业务流程改进或业务流程优化）。但在实施过程中往往走到另一个极端，无论用户还是顾问公司都尽量回避“BP”，这就又错了。

    　企业在实施ERP以前，信息不共享，无论是有部门级的信息系统也好，还是完全的手工单证管理也好，部门间都存在信息壁垒，形成一个个的信息孤岛。组织架构以职能建立，多是树形的科层制组织结构。部门间不仅存在信息的壁垒，权利也存在壁垒，部门利益主义横行，跨部门的工作协调的工作量很大，甚至协调的难度也很大。

 　   ERP的设计基于信息共享平台，强调物料流、资金流和信息流的统一。基于全程供应链的管理思想，供应链管理思想要求组织结构是跨职能的水平型结构。供应链管理须要协调大范围内的活动与流程。这些活动与流程往往跨越职能部门，包括采购和发料、进出口运输、接货、物料处理、贮存和配送、库存控制与管理、供需计划、订单处理、生产计划、运输、加工，以及客户服务等等。这些活动被看作是一个前后关联的系列，它们需要整合、协调与同步，这就是供应链管理的本质。所以，在ERP项目的推进过程中，要让用户彻底理解供应链管理的实质，接受供应链管理的思想，要让用户意识到他们每天从事的工作是一系列关联的活动，而不是分散的、孤立的活动。如果认识不到这一点，在涉及到跨部门或跨职能边界寻求效率改进的机会时，就总会遭遇到来自这些部门的直接阻挠。但十分遗憾的是在很多ERP项目的实施过程中把这个环节忽略了。
   　 德勤顾问公司（Deloitte Consulting）的最新调查指出，北美91%的制造商将供应链管理列为最关键或非常重要的企业成功因素。

   　 当然，变革需要条件和机会。我们相信，项目推进过程中，为了降低项目的风险，首要的是供应链管理思想的普及与渗透，在管理层与执行层完全理解的基础上推进变革。变革是一个持续的过程，不是一蹴而就，也不是一夜间的变化。变革的动力要有持续的支持。

    　ERP的系统跑起来只是第一步，用的好需要“形”和“神”的统一。
   
    3. 来自项目管理的风险和规避
    　项目管理也是一门学问，现在已经得到越来越多的人的重视了。

    　作为一个项目，其目标和范围首先必须是明确的。但实际的ERP项目往往又是模糊的，用户方面和顾问方面在这里往往都存在侥幸心理，一方想稀里糊涂地多要点，一方想稀里糊涂地少做点。都会给项目带来风险。项目启动之后，合作双方已经完全被绑在了一条船上，没有你我之分，成功与失败对双方都一样重要，这个时候，双方要实事求是地评估项目资源（即投入项目的资金、时间和人力），制定切实可行的项目目标，圈定切实可行的实施范围。很多项目在完成之后也无法明确项目的效果，缺乏项目实施前后量化的指标比较，这就提醒我们，在项目启动之初，双方要尽可能收集业务过程中的可测量的指标，如库存周转率、库存资金占用、按期交货率、一次检验合格率、客户投诉率、财务报告时间等。

    　项目组织的完整性是对项目成功的保障。通常需要有合作双方高层参加的项目领导小组，负责保证和协调项目所需的资源，决策项目相关的重大变革。双方合作的项目小组是项目推进过程中的常设机构，必须确保项目小组中人员的稳定性和对工作的胜任。

   　 我们必须看到，ERP项目不同于小型的业务管理系统，它是一个几乎覆盖企业所有业务部门的系统，而且在实施过程中还会牵扯到组织和流程的变化，甚至权力和义务的重新分配，ERP项目的推导是一个复杂的系统工程。把一个对开的年画挂在墙上是一件容易的事情，相信十几岁的孩子都可以做到，但是要把一幅几十平米的广告画平整地挂在广告牌上，就不是一件容易的事，既需要技术也需要方法。顾问公司在帮助用户实施ERP项目的时候，既在项目方案方面给客户带来帮助，在项目实施方法和项目管理方面带来的价值也不可小觑，事实上，后者对把控项目的质量和风险更加重要。

   　 各家主流的ERP厂商都在不厌其烦地推介自己的所谓实施方法论，但真正理解项目管理精髓的ERP项目经理仍然还是今天社会的稀缺资源。项目实施方法不是一成不变的，笔者以为，项目实施方法一定会依据项目对象（用户企业的规模和用户方项目组成员的素质因素等）、项目范围、项目实施周期、顾问水平等作适当的调整，不可能形而上学，一成不变。重要的是抓住项目管理的核心要素：范围、时间、质量、成本。

   　 一个客观可行的项目计划非常重要。项目上线时间及系统切换时间的宣布一诺千金，绝不可以轻易变更，特别是延期变更。只要有一次有理由的延期，项目组成员和最终用户就会对项目计划不以为然，他们会相信做不好工作一定还可以有下一次的延期上线的决定。我也不建议在安排项目计划的时候，留出所谓的Buffer，项目计划中有了预留的宽容，会给计划的严格执行留有余地，从项目的一开始就给项目组留下了讨价还价的空间。在项目上线时间临近，资源又不能充分保证的时候，宁肯砍项目上线的范围，也要保证项目上线的准时。

　
    有效的项目管理还必须要做到有效控制用户对项目的关注焦点。项目的成功与否，着眼点应该在全局，而不在局部，绝不可以因个别用户或者个别顾问的过于专注把项目带入局部的精雕细刻。一个项目的推进，好比给一个木箱装箱盖，箱盖四个角的螺丝要轮番循序渐进地拧，绝不可以把其中一个拧紧了才去拧第二个，那样做，无法把箱盖平平整整地拧上去，拧到最后还不得不把已经拧紧的螺丝再退两圈下来，搞不好还会把箱盖拧裂。
   
    4. 来自数据的风险和规避
   　 人们常说两句话，一句叫作“三分软件，七分实施，十二分的数据”，另一句叫作“垃圾（数据）进，垃圾（数据）出”，足以见数据对项目的重要。

   　 项目实施过程中，顾问要在方案确定后，就及早与客户讨论数据格式，编码规则等规范，帮助客户制订静态数据的数据收集模版，并定期跟进客户的收集过程，确保按计划完成。

    　项目上线前的动员，要再次向全体用户重申数据的重要性，强调数据录入的及时性和准确性。上线初期，项目组对每日的数据的准确性都要做检查，要出数据差异报告，随着数据准确率的提高，数据差异报告的发布周期可以改为一周。必要时，系统数据差异的总结可以成为公司周例会的一个内容，充分加强各部门主管对数据准确性的认识。不少的企业在系统上线初期，甚至采用奖惩手段来确保系统采集数据的准确性。(E-works)