所以，他们的总经理决定要上马ERP项目，但是，他们又不想拿出太多的钱投资在这个上面。故，他们准备采取开源的ERP项目，并且，自主负责实施。为此，他们还专门从ERP软件公司高薪挖来一个ERP实施顾问，负责企业的ERP项目。

　　在实施过程中，ERP实施顾问要简任两个角色，一个是ERP实施顾问，另一个是ERP程序开发员的角色。因为他们选择的这个开源ERP产品(其实，大部分的开源ERP产品都是如此)，功能不全，特别是生产管理的功能。如没有MRP计划，就不能根据销售定单或者生产计划生成物料申请单或者采购单;生产领料时，只能执行自动扣料制，不能执行发料制;如成品入库时，必须一次性入库，不能分批入库;再如，没有工艺管理模块等等。

　　这些功能上的缺陷，都要实施顾问自己开发定制。虽然，这个开源软件提供了一个开发平台，可以减少一定程度的程序代码编写，但是，如MRP计划等等，仍然需要大量的代码才能完成。而且，程序完成后，还需要大量的测试，没测试，顾问是不敢拿出来推广的。万一哪里出点问题，顾问很可能变成过街老鼠，人人喊打了。

　　同时，因为开发的工作量大，而上头又逼的比较急，所以，在实施过程中，不得不分部门实施。实施顾问先上了销售部门的模块，然后再上采购模块，然后再上生产模块。如此分部门上，虽然是一个不得已的办法，毕竟，顾问不能分身呀，如此大的工作量压在他身上，只能如此。但是，这么做有很大的局限性。如采购、生产、仓库三个部门是有机的一个整体。

　　试想，若先上采购再上生产，则原材料只有进没有出，那库存根本就不可能准确，因为库存数量都是有增无减，何来准确性的说法呢;而成品仓库的产品，又只有出没有进，仓库的库存数量永远都是负库存。这库存数量的不准确，连最基本的净需求都跑不出来，企业只好暂时以毛需求来考虑物料需求计划，即不考虑库存数量，定单需要多少材料就用多少材料。还好，企业的大部分生产定单都是按单生产，这让ERP实施顾问，暂时送了一口气，可以暂时不用管净需求。

　　而且，企业在ERP实施的过程中，非常重视表单的格式。如采购订单，一定要求跟现有的采购订单格式一模一样。但是，现有采购订单的格式又实在不让人苟同，在采购单上竟然要带出销售订单的号码;更加匪夷所思的是，还要带出对应的成品编码。他们的理由还很充分，但是，都站不住脚。如他们说，这是为了供应商的需要，因为供应商看的是成品的编码，零件编码他们反而不关心。

　　这个理由能站的住脚吗?即使有理，企业为什么要屈服与供应商吗?为什么不让供应商来配合企业呢?实施顾问为此斗争了几天，做出了不少的努力，但是，仍然不能说服用户，胳膊能扭过大腿吗!没办法，对于实施顾问来说，用户就是客户，就是上帝。只好违心的按照他们的需求，设计表单。表单设计好以后，问题又出来了，格式跟他们现在的格式不一致。顾问出于标准合同格式的考虑，把销售订单号码放在了销售订单的结尾，但是，原由的销售订单号码是放在最后的。采购员看着不顺眼了，一定要顾问把他放在开头。如此小的格式问题都不能妥协，这让实施顾问非常吃力。拿人家的钱嘴软，没办法，实施顾问只好再次调整格式，以讨得他们的欢心，让他们再也不能鸡蛋里面挑骨头。.

[1] [2] 下一页