[原创]拿什么拯救你，ERP？

    钟剑不知道怎么走出会议室的，下意识向十五楼去走，上了四层楼就感觉气不顺，楼道安静而气闷，额头上开始冒汗了。

    “公司花费了上千万、投入了几十个人的精力，为什么ERP项目拖了一个月还是无法上线，这样一种混乱的局面是什么原因造成的？”刚刚过去项目进度汇报会上，面对问题一堆，CEO王总责问道：“钟经理，你们信息部在‘脚踩西瓜皮’，作为项目经理，你应该好好思考一下，明天给我一份报告，告诉我原因和解决方案！”说完摔门而去，把项目组成员扔在会议室里，大眼瞪小眼。其实，这也不能怪王总，刚刚项目阶段汇报会议上，各部门反映的情况也真够乱的：

   → 销售部门营销平台的数据通过接口导入ERP系统时，跨月部分产生重复；

     → 生产计划通过MPR计算出来的结果，与目前人工计算差别过大；

     → 采购订单行项目数据无法自动带到入库单上，需要手工重新的录入；

     → 财务报表无法正确显示，会计科目平衡表数据是正确的，但资产负债表一直不平；

     → 仓储存货帐与财务帐面无法做到帐帐相符，存货帐与实物帐也存在着一定的差距；

     → 业务部门最终用户在培训操作过程中，发现操作手册上写的内容在系统中根本就找不到，或有出入，且相对比较简单；

     → 虽然经过单元测试，但测试的场景过于简单，没有含盖日常业务运营的全部内容；

     → 在最终用户操作培训的过程中，很多业务部门自己上报的参培人员也没有参与过一次ERP的相关培训；

    业务部门投入到项目组的关键用户，大多数是本部门的骨干，但由于他们的工作繁忙而没有全力投入项目，造成关键时候找不到人、与其有关的关键问题讨论亦不在场的现象，使得会议一拖再拖，尤其是销售大区和某工厂的关键用户连一次最基本的ERP功能培训都还没有参与；

    ……

    钟剑一边回忆着会议上的情况，郁闷地转出楼道门乘电梯回到自己位于十五楼的办公室。一年前，通过猎头进入这家生产型企业，经过调研、分析，在了解企业信息化发展现状和业务特点后，提交了公司IT三年建设方案。然后按部就班地着手基础设施的建设、IT部门的团队建设，慢慢熟悉并融入该企业。去年年底ERP系统建设列入公司重点项目计划，这也正是钟剑过来的动因。虽然在原来的集团公司经历了国外大型ERP项目实施的过程，但角色只是其中一个组的组长，负责某一小块具体的业务流程设计和系统实现工作，没有能够参与项目管理的内容，一直希望能够作为项目经理全程参与和统率一次ERP项目。

    ERP项目正式列上议事日程后，钟剑在业务需求调研后，严格按照ERP实施的标准方法论，进行了系统选型，最后选择了国内某大型ERP系统软件。对实施的顾问团队，也是一个一个简历看过，个别还进行了面对面的交流，可谓精心挑选。经过半年的努力，终于到了即将上线的最后时刻，项目停滞不着，出现了上述的混乱而复杂的局面。这些究竟是如何产生的？钟剑收回思絮，打开工作目录下ERP项目文档，一项项井井有条地展现在眼前：

    项目计划：

    在项目准备阶段，项目计划的编制成为甲乙双方两位项目经理的主要工作内容，将六个月的总体上线任务和工作内容细化到周、甚至到日，并在项目主计划统驭的同时，进行了数据计划、项目整体培训计划、项目宣传、活动计划等内容，以确保项目计划的周密而不遗漏。

    “计划没有变化快”，由于人员投入的缺乏，项目虽然按着计划在向前走，但总是存在着这样那样的问题，无法做到深入和完善。而最终导致系统上线推迟的最主要原因就是期初数据迟迟没有收集整理到位。

    项目组织：

    项目组织的建设也是起初脑筋动得比较多的地方，成立了项目管理委员会，将公司主要高层都纳入其中，由CEO亲自担任；管理委员会下设项目管理办公室和监理组；接下来是技术组、业务组、数据组和开发组。其中业务组按此次上线的模块分为五个组：销售、采购/仓储/物流、财务和生产，业务组长均由相关业务部门负责人担任，再由其抽调部门骨干进入，同时信息部也在每个业务组派出一名代表。

    起初，钟剑一再要求业务组必须有一名业务部门的骨干力量全职参与项目组，但最终由于业务部门负责人的反对，而导致目前业务组除信息部人员外全部处于兼职参与。经常一个讨论分析会都要一变再变地变更时间，尤其到后期的跨模块的讨论更难确定会议的时间，加之项目组没有一个统一的工作场所，顾问、业务组、信息部人员均在各自的办公室办公，只有开会时再聚到一起。由此，对项目所有工作的开展都产生了巨大的影响。

    蓝图设计和系统实现：

    由于前期准备工作比较充分，ERP项目启动前已经做过一轮业务流程的调研分析，加之ERP项目刚刚进入大家的视野，在蓝图设计中现状调研阶段，大家还是比较积极地参与，很快就完成了任务。但到了未来蓝图设计时，一是由于工作忙，二是“新婚期”已过，个别部门领导不再参与流程的讲座和分析，而由手下人参与，领导只看最终的汇报和文档，并也在蓝图流程上签字认可了，这些在当时并没有觉得问题有多大。但到了最终用户培训和单元测试时，却发现原来这些蓝图流程与老总们想的有出入，与那些部门的骨干的思维也有出入，只好返工重来。还需要协调实施顾问的资源，在原本时间和人力资源比较紧张的情况下，又浪费了不少时间，让人苦不堪言。这也是上线时间延迟、项目计划不能顺利的主要原因之一。

    系统实现，一方面是顾问按业务蓝图流程设计进行配置和二次开发，另外就是关键用户熟悉系统、并进行业务场景在系统中进行测试运行的好时机。仍旧由于人力的投入不足，导致很多地方就由顾问进行相对标准的测试就草草了事，有些虽然由关键用户进行的，但由于系统熟练程度有限，加之大部门关键用户没有引起足够的重视，但测试当成一项工作任务来完成，应付了事，没有完全重现业务运作时的多重组合的复杂的业务场景，相对简单地进行了一些业务内容的测试。这为准确上线埋下了风险。

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

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