CIO踩到西瓜皮 拿什么拯救企业ERP？

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

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

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

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

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

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

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

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

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

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

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

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

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

项目计划：

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

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

项目组织：

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

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

蓝图设计和系统实现：

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

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

数据整理和接口、报表设计：

数据，从一开始就提到比较高的地位，专门成立了数据小组来负责，静态数据很快就进行了统一编码、重新规范等工作，动态数据的模板设计和下发也进行得相对比较顺利，但在业务部门却没有引起足够的重视，或者没有及时提交、或者提交上来的数据没有完事地按模板进行填报，有些业务人员就象征性地填了一两列数据荐就上交。因此，数据的整体收集和整理工作一拖再拖。

另外，由于公司从建立到现在也有十五年的，历史遗留下来没有解决的问题比较多，集中反映到数据上就是：帐实严重不符，日常在进行审计和核对时，大家只采用帐帐核对，而只有一些常用的原辅料和流动比较快的产成品在正常流转。这也是不同业务部门在上线数据不符调整时，争论的比较多的事情。

虽然公司其他的信息系统并不多，但由于整体行业信息化程度比较高，上下游企业之间的数据传输还比较频繁，为了解决这个问题，在选型时即确定通过接口的开发来完成。这块由于顾问公司人力投入的不足，而信息部提交的开发技术人员招聘的事情也被莫名搁置了几个月，到目前为止还没有任何信息。

报表开发需求量也比较大，虽然已经开发好其中的一部分内容，但由于系统没有真实数据，很难对其正确与否进行评估和检查测试。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。