如何盘活失败的ERP

第一篇：如何盘活失败的ERP

如何盘活失败的ERP：从一则失败的案例说开来

一个投入上千万的大型ERP项目上线延期了。上至董事长，下至业务主管，所有的怨气都要撒在ERP项目主管钟剑的身上。问题出在哪里？天时、地利与人和，到底是哪一方失利？面对ERP乱局，唯有逐条分析原因，才可以对症下药，解开难题。在逐条捋清问题后，钟剑使出了他的撒手锏，问题迎刃而解。

案例篇

ERP失败算不得稀罕事，但是找到败因，力挽败局，就不是一般CIO都能顺顺当当做下来的了。面对即将或者已经失败的ERP项目，很多CIO会选择遮掩下来，毕竟从选型到实施自己都是项目经理，承认项目失败就是认定自己无能，更不消说领导面上无光，企业形象受损。

如何能在败局中取胜？这家大型生产企业的ERP项目经理钟剑自有一套。

发难

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

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

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

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

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

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

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

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

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

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

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

„„

回溯

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

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

项目计划：

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

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

项目组织：

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

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

蓝图设计和系统实现：

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

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

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

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

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

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

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

最终用户培训：

《最终用户操作手册》每个模块在顾问的督促下，在关键用户开始学习的时候就着手编制，只有少数没有关键用户投入的部门涉及到的操作流程未能完成。由于关键用户对于业务的熟悉程度不同、对ERP系统的熟练程度不一，操作手册的优劣差异很大。相对来说业务场景设计得比较全面，且能够详细截图、解说的《最终用户操作手册》不多，这也为最终用户的培训带来了问题。

在最初的培训计划中，安排的是专门的多场集中式培训，但由于业务部门工作繁忙，关键用户和最终用户时间无法统一调配，使得培训的方式变得五花八门：有集中进行培训的，有单一进行培训的，还有到最终用户工作现场进行培训的。

反思

王总让钟剑整理一份情况报告，虽然在项目推进的过程中，上述问题都已经通过项目进展通报提交给公司高层和业务部门领导，也在会议上做过汇报和总结，并提出过应对措施，但可能是没有触及到他们的痛处，没有引起足够的重视。钟剑想，看来这一次不能再不痛不痒了，已经受到王总的责难，那就索性和盘托出，痛在一时比一直痛下去要好。

综合前面的回顾和分析，项目主要存在的问题是：

1.人员及精力投入：业务部门没有足够重视，虽然项目组里挂名的都是各个部门的领导，但真正投入的时间和精力的非常有限，个别部门虽然在项目的后期有专职常驻人员，但对业务本身的熟悉程度有限。制丝车间到现在连一个人都没有参与过，销售部西北大区连一个兼职人员都没有来听过课，而工厂的财务部成本会计居然从未露过面。

那么，这一块问题的解决，需要引起公司各部门领导足够的重视，并由项目管理委员会负责人CEO王总亲自发布命令，按最初项目组织的要求，抽调各部门得力骨干，全职参与到项目中来。

同时，需要有一个统一的办公环境，让项目办公室、实施顾问、关键用户坐到同一个办公室中去，以便充分交流，也使得顾问的知识快速传递给关键用户。

2.数据整理：虽然经过项目组的努力，基础数据已经有了一定的规范，但那些日常运营的动态数据却迟迟不能收集到位，虽然数据也都采集上来了，但数据本身是不完整的，而主要的物料数据普遍存在着财务账和业务账无法“账账相符”，更不要说业务账和实物之间的“账实相符”了。

针对上述问题，需要动员所有业务部门，重新组建一次数据收集、整理的队伍，针对历史遗留问题进行认真分析，能够核对清楚的进行调账处理，不清楚的部分先打包进入系统，待后续阶段有精力时再进行解决。

3.业务测试场景设计：在业务测试和最终用户手册编写环节，由于顾问对公司的行业熟悉程度有限，协助关键用户进行的单元测试和集成测试场景设计相对简单和标准，没有考虑到业务的复杂变化，而关键用户的精力投入有限，大部门人都把测试当成一个任务而已，没有引起足够的重视，只是简单地设计并做了系统测试。而当最终用户参与学习时，有大量没有经过测试的业务情景出现，结果导致或者没有办法操作，或者问题一堆，再加上系统数据的缺失，使得业务部门最终用户对系统产生不信任感。

需要组织业务骨干，收集和整理日常业务不同的场景变化，统一编辑后，进入系统进行测试，并添加到《最终用户操作手册》中去，为今后最终用户的学习提取更翔实的指导。

4.需求变更：项目开展的前期，业务部门没有足够重视，在业务调研和流程梳理过程中，部门领导和关键业务骨干投入的精力有限，整理出来的业务流程细度和准确度不够，而在最终用户操作培训时，又提出了新的业务需求，且这些需求很多会引起较大的业务流程变更。

对于新提出来的需求，以不阻碍业务正常运转为前题进行筛选，关闭那些与界面、操作习惯等有关的需求，待ERP上线后再慢慢进行优化。

想到这里，钟剑不由得露出了一丝苦笑，其实在项目刚开始组建，以及后来的项目实施过程中，这些问题不止一次地提过，当时王总和各业务老总应允得很好，但最终结果却无法让人满意。他本想把这个项目建设成“公司级”的信息化建设项目，为自己的信息化职业生涯别上一枚金制奖章，最终，在实际项目推进过程中连“业务部门级”项目都没有达成，而沦落为“信息部门”的建设项目。这些是他这个信息部经理无法改变的。

这次的分析报告如果再不点醒高管们，这个ERP项目的走势很明显，而自己在这家公司的职业生涯估计就走到头了，职业生涯中的“污点”也就此留下。钟剑希望能够就此机会反戈一击，一举扭转几个月来的被动局面，给ERP项目成员注入强心剂，做成一个先苦后甜的好案例。

下定决心后，钟剑坐下，信心满满地准备继续“笔伐诸侯”„„

分析篇

项目组不能做摆设——河南饭店CIO 王大龙

俗话说兵马未动，粮草先行。在ERP项目实施过程中，项目组织的建立是项目正常运行的保障。通过上述案例，我们可以看到该公司的ERP项目组织是按项目管理的标准进行设计的，但在实际过程中却没有发挥应有的职责，从而使项目管理组织失去了应有的功效。

从项目管理的角度来说，项目组织的建立是项目正常运行的保障。在ERP项目实施过程中，当然也要遵循建立项目组织的原则。但是分析上述失败案例，我们看到该公司虽然完全按照项目管理的标准来建立ERP项目组织，但是显然只有皮毛没有深入，失去了其应有的意义。

管理上要各司其职

首先，我们先来看一下一般ERP项目的组织和对应的职责。

项目指导委员会：负责组织审定项目计划、实施方案，指导项目开展、重大问题协调与决策。

案例中，项目指导委员会没有发挥应有的作用，看到的只是责难和推卸责任。

项目管理办公室：具体负责项目日常组织工作，负责制订项目计划、实施方案，控制项目进度与质量，协调解决出现的问题；负责整体ERP项目管理与资源协调，以及关键实施问题的解决；负责向项目指导委员会提交各类汇报材料，负责项目各类文档的组织与评审，验收准备工作的组织。

案例中，我们无法看到资源调配和协调，由于实际权力的缺失，只有一味地让步和等待。当然，这是目前市场上最常见的现象。

业务组：保证业务需求明确清晰；对未来流程以及系统方案提供建议；负责与相关部门的沟通协调；协助解决项目执行过程中的业务问题；负责流程改建与优化的具体落实；培训最终用户，帮助其掌握ERP系统使用；解决常见的系统应用问题；向项目组提交不能解决的系统问题；负责进行有关的应用系统配置和管理；负责相关管理制度细则的起草和监督执行；汇集并提交销售业务和归口审批的报表及功能性开发的需求整理并提交模块优化及完善的新增功能需求；建立涉及管理与维护相关文档和问题处理日志等。

从案例中我们可以看到，该公司的ERP项目是定位到“信息中心部门项目”的层级，业务部门对于项目是被动的参与，而不是积极主动地展开工作。

技术组：负责相关模块的报表开发和功能增强，协助各异步系统接口的标准化搭建，初始化数据的导入、历史数据的处理等工作，负责项目全过程跟进、学习，并负责系统的后期日常维护工作。

数据组：进行各异步系统接口的标准化搭建，初始化数据的导入、历史数据的处理等工作。

运维组：负责网络、硬件、数据库、操作系统的维护，确保ERP运行环境的正常。其中，数据库、操作系统等的维护由专职ERP系统管理人员担任。

综合组：主要承担项目协调，事务性工作安排，文档管理以及对外、对内的宣传工作。

如上图所示，我们可以看到ERP项目组人员来源于企业内、外部的各部门和单位，并根据各自承担的职责和所在部门，进行一定的划分，并在项目中逐步成长。项目结束后，一部分关键用户回到自己原有的部门，或者被提升到新的部门，而有一些项目过程中表现优异者，将作为未来信息中心组建的重要来源。

从深层次抓问题

表面上看，案例中客户的ERP项目组织非常宠大，但从案例分析得出来的结论看，项目组的工作环境和人员问题越来越突现：

首先体现在工作环境上。一般ERP实施项目的工作环境和氛围，是统一的、团队大家庭的工作环境，大部分成员是来自不同部门的专职人员。

ERP项目实施是一项管理变革，而变革最重要的一个条件是达成共识，需要有充分的交流和沟通，相对集中的办公环境、长时间共同作战的氛围都是非常必要的，所谓“抬头讨论、低头研究”是ERP一种常见的工作状态。

ERP系统是知识密集型的软件系统，需要不断地学习和钻研，知识转移也是个潜移默化的过程，关键用户需要大量的时间去学习、使用，统一的办公环境可以使得这样的效果事半功倍。

信息化建设从其根本上来讲，是改变人们日常工作的习性，所谓“江山易改，本性难移”，任何人面对变革都存有拒绝的心理，尤其当改变的人来自团队的外部时，其抗拒心理会更强。

其次再看项目成员。

整个项目成员90%以上处于兼职状态，尤其是业务人员的时间无法保证。

由于业务部门人员不到位，信息部人员承担着项目实际上的主要工作任务，一人多岗，身兼数职，苦于繁锁的记录和组织协调工作。

项目实际参与人员以集团总部成员为主，各地工厂和销售分支机构人员参与较少，甚至没有人来参与。

关键用户没有时间研究和学习ERP系统的基本原理和系统操作，会影响到未来上线后系统的正常运行和业务的开展。

业务部门人员兼职方式，在时间上无法保证，从而影响到项目的进度功能以及准确程度，导致顾问配置好的系统没有得到及时和应有的测试。

由于业务部门重视程度不够，没有让相关人员参与项目，导致数据收集、整理迟迟不能完成，导入系统工作一直无法进行。

分支机构人员参与较少，让人担心其业务的实际情况是否调研充分，系统是否满足他们的需求？未来系统上线时会出现抵触的心理和情绪，给项目的进展带来不必要的麻烦。

开发人员到目前为止只有一人，招聘报告提交已经有半年却迟迟没有招募到位。

杜绝潜在风险

目前，项目组织和人员成为阻碍项目进度的最关键因素，从整个项目实施来看，其风险具体表现在以下几个方面：

过多个性化的需求。基于ERP标准的套装软件，很多需求都要进行二次开发，目前只有一个内部的开发人员参与，不可能承担起未来的系统报表开发和二次开发任务。

根据对人员和工作环境等情况的综合分析，给出以下建议：

1.基于现有项目运作状态，业务部门增加人员全职进驻项目组，同时让未来主要操作系统的岗位人员尽量学习和熟练系统的操作。

2.抽调各地人员参与到项目组里，接受培训和测试任务。

3.加快技术开发人员的招聘速度，尽量在顾问公司离开之前能够进行系统未来二次开发及报表开发的学习和实践。

4.各业务部门领导真正关注ERP系统未来的业务流程，清楚系统上线的重要性，认识到未来其对业务带来的变革。

5.重新审视与实施公司签定的合同，合理要求实施公司增派人手并加大支持力度。

6.最好能够给项目组一个短期可以集中在一起工作的环境。

有了高效的项目团队，在重新上线时加以合理的利用，彻底改变“只挂名而不干实事”，或者“人在曹营心在汉”的情况，切实履行项目组织中各自的权力和义务。这些能够为未来的系统重新上线奠定基础。

模拟上线前须严把测试关——AMT咨询高级顾问申晴

用户信心不足、不知系统是否准备充分，这些通常都是由于项目组对ERP系统的测试不够充分、不够全面造成的。模拟运行可以认为是更加贴近真实业务、更加全面、参与人员更广的系统集成测试，这是一个系统成功上线的必要保障。

通过案例中钟剑自己的分析，从整体的项目进程来看，一切都在进行中，上线拖延的一个主要原因是系统没有得到有效的测试运行。这与笔者曾经经历过的一个ERP实施项目很相似。

一般ERP项目实施到即将上线的时候，大家往往都会产生一种很忐忑的情绪，这样的情绪在很大程度上影响了系统上线，正因为如此，模拟上线和测试就显得尤为重要了。

不良情绪影响上线

项目上线前，很多时候会有一种不良情绪显现出来，分别是：

第一，项目管理办觉得心中没底。作为项目的组织协调机构，项目办公室虽然对整体的局面有一个全面的把握，但是很多细节却没办法全都深入去探究，各项工作虽然按计划在开展，但是是否还存在问题无法知晓。此类大型ERP系统上线后一般都不会与原先的系统并行，业务的正常运作将完全依赖于新系统，正式上线后到底会出现什么问题，应该如何应对，大家心里都没有底。

第二，新系统能否完成业务需求？这是业务部门各层面人员最主要的担心。业务部门领导对于系统能否支撑实际的业务运作存在忧虑，虽说项目组已经开展了几轮的测试，但是由于没有真实运营数据的支持，系统的正确性无从判断。

第三，关键用户关心未来如何应对发生的问题。关键用户是工作的主力，系统上线后有多少问题、如何响应是他们关心的问题。

第四，最终用户关心如何面对未来的新系统：虽然经过了相关的操作培训，但是对系统的运用熟练程度有限，如果出现一些突发的情况更不知道如何应对。

而作为实施方，对于系统上线是非常清楚的，让他们头痛的是如何让业务部门的相关人员积极地参与到上线相关的准备工作中去，保质保量按时完成准备工作，从而实现系统的按时成功上线。

对于业务人员，由于缺少直观的认识，对于部分工作的重要性是很难与实施方顾问有相同的认知的。

按照ERP的实施方法论，项目组已经开展了必要的工作，应该采取什么措施来进一步提升项目组各方人员的信心，让系统上线更加顺利呢？

真实地模拟

针对目前这种状态，笔者认为：究其原因主要是由于项目组成员对系统上线缺乏直观的认识；其次，系统未经过实际业务测试导致其适用性受到质疑。因此，在系统正式上线之前，需要针对业务的真实数据和场景，进行预盘、预导、预测，应用真实数据对配置好的系统，进行一次真实的模拟可以说是一个很好的提前防范风险、提升用户信心的方法。

模拟上线，可以理解为将企业在一定时间范围内的真实业务，按照预先设计好的业务流程和操作规范，在已经基本配置、开发的基础上，将初期真实业务数据导入的ERP系统中进行重现的模拟运作。

企业开展模拟上线首先要弄清楚希望达到的目的，由于不是正式的系统运行，企业在模拟时应该更多关注过程中各类问题的发现、记录和解决，以及整个过程中工作经验的总结。不要过多纠结于最后数据的完全准确，而应该将重点放在对差异的分析上。

通常模拟上线的目的有以下几方面：

检查系统准备度 通过实际业务的模拟运行，全面检查整个ERP系统在功能、权限、数据、报表以及硬件网络方面的准备是否充分，是否具备支撑实际业务操作的能力。

提升用户信心及操作水平通过模拟运行，对系统正式上线前后的所有工作任务进行演练，消除项目组成员的未知心理，提升用户信心；同时，通过全面的业务操作进一步锻炼各级用户的操作水平，增加操作熟练度。

发现问题、提前防范 通过模拟运行，将正式上线将会暴露出来的问题，提早暴露出来，针对不同问题给出解决方案，提早做好准备，降低上线风险。

增强紧迫感，全体一心保证上线 通过模拟运行，业务人员切身感受到系统上线对自己工作的影响以及上线任务的紧迫，促进全体人员目标一致地积极投入到上线任务中。

由于涉及到企业经营的方方面面，且在时间上不是实时的业务操作，模拟上线计划的制定和严格执行对于模拟上线非常重要，什么时候做什么业务，谁先做谁后做，做几笔业务，做多少数据都要严格按照计划执行，否则会大大降低模拟上线的效果，也失去了真实业务数据模拟的意义。

通常模拟运行会涉及到一个期间内完整的业务流程，首先需要理清整个业务流程的逻辑关系，明确各类业务的先后顺序；

其次，对于每一个业务需要具体的操作步骤进行指导，要明确每一个业务的操作名称、描述、操作人、事务代码以及所属的模块等等：

通过详细的计划编制和严格的执行来保证模拟运行按照预先设计好的流程走下去，才能使得预先设计的结果与系统运行的结果具有可比性，能够分析出差异的原因。

模拟运行过程中，需要设置专门的监控人员对整个过程的重要环节进行监控，以保证关键环节的正确性。监控人员要具有高度的责任心，及时监控各关键监控点，发现问题应及时向相关组织汇报，及时更新问题清单，并且负责跟踪后续问题的处理。

模拟运行的监控点通常可以从数据、关键业务方案、接口以及报表等几个方面着手。数据监控可以包含初期数据的整理、库存金额确认以及数据量等；关键业务方案则可根据企业实际业务运作，确定重要的业务流程或操作进行监控；接口监控则可以根据ERP系统相关的集成系统，检查指令或者数据传输的及时性、准确性；报表监控则是看一些主要的业务统计报表、财务报表是否能够出来，且相关数据的准确性，重点在于找出差异原因。

模拟中的常见问题

正式上线时会碰到的问题，模拟运行时都有可能碰到，模拟运行中出现问题对于项目组来说是一件幸运的事情，可把问题在正式上线爆发前予以发现并解决。各类问题表现形式多种多样，归纳起来主要有四大类。

1.权限类问题 权限的缺失、错误通常是刚开始集中爆发的问题，其主要原因是业务部门对最终用户将来操作系统时所需要的权限不清楚或提报最终用户时存在遗漏引起的。

2.系统操作类问题 通常的表现形式为最终用户不能独立的完成试上线需要进行的系统业务操作，对某些业务流程不知道该如何选择对应的操作等。

3.业务流程类问题 包括系统流程与现有流程不吻合的部分，造成没有人能进行对应系统操作，某些系统流程在实施层面存在岗位不清晰、不能落实到人的情况，造成应该操作的用户却没有相应的权限等。

4.数据类问题 数据通常是系统运行中碰到问题最多、影响最大的问题，包括静态数据的错误、缺失，编码不对应以及动态数据中期初数据错误、异常业务数据、账目不平等。

对于上述问题不仅要解决，还要分析原因，总结经验。有些问题模拟运行时出现了，很有可能正式上线还会出现，比如权限问题，因此要及时建立问题的应急处理机制，将模拟运行中总结的经验运用于正式上线时的问题处理，提升运作效率。有的问题是企业本身的岗位设置不明确，那么就需要在组织层面将职责划分清楚。因此，通过模拟运行中发现问题后，不仅要解决系统过程的操作问题，还应当关注其对正式上线时项目组工作的借鉴意义，总结归纳并充分利用。

针对上述案例，建议进行一次模拟上线，应增加业务人员的信心，呈现目前还存在的问题，为最终的系统上线打下基础。

第二篇：新华书店ERP失败案例分析

新华书店总店实施 ERP 案例失败分析

新华书店总店的项目总结起来就是一句话一个陌生的队伍拿着一个陌生的软件到一个陌生的领域为一群陌生的对象服务。没有不失败的但经验和教训却值得我们现在以至未来参考。

新华书店总店 1998 年开始实施企业进销存系统。新华书店总店是国内图书发行行业最大的批发商年销售 17 亿元年发货册数 8 千万册面对 3000 多书店客户年发货 100万笔。对于信息系统要求较高。原先的系统从 1985 年开始严重老化需要上马新的系统。聘请 15 所的一支开发队伍进行 SAP 系统的开发。开发工作从 1997 年的 12 月开始到1999年 9 月份上线遭遇滑铁卢全线失败。首先是系统极其慢原系统 2 秒钟的处理到了 SAP 系统中需要 30 分钟系统在只有一个人用的时候能达到 2 秒钟当并发到 100人的时候竟然退步 900 倍包括 SAP 本部一筹莫展其次是有些简单功能无法实现因为 SAP 是标准制造业的系统流通业的功能有区别但没有办法更改底层的系统语句三是系统开发人员凭借开发了 SAP 不断跳槽到新公司项目组队伍分裂。最终新华书店总店与开发单位协商撤掉 SAP换了一个队伍重新进行开发。教训是：

一、慎重进行大的系统开发。ERP系统涉及范围广、难度大企业必须在有相当大的决心进行现代化管理的前提下才能提得上进行 ERP 的开发。当企业的标准化管理达到相当的程度时内部开发 ERP 才具备了条件。

二、内部队伍建设为基础。有了现代化管理还不够需要有一只经过锻炼的 ERP 内部实施经验队伍。当然这是很难做到的。但是必须有几个工程师确实经历了大的开发工作有了比较好的经验。同时这些人对于企业的情况非常熟悉对业务流程很了解。这个队伍才会有实力接待外来的开发队伍。

三、深入调查研究。前期的双方调研怎么细致都是不过分的充分了解企业内部的需求同时到同行那里去了解系统的应用情况。掌握大量一手的材料个人和集体开会分析项目小组的内外成员都要掌握共同的知识。尤其是要了解领导的思想与领导就项目的边界达成共识与主要部门的领导达成共识。

四、用户原型很重要。由于企业内很多人对于系统了解少缺乏专业知识所以把系统原型开发出来供一线人员直观地了解则是非常重要的。这样可以取得需求人员的理解并获得支持。

五、慎重选择系统。由于 SAP 的优秀吸引了很多 IT 人士禁不住诱惑劝说用户购买这个系统。但是SAP 对企业的要求很高只能适应那些与程式化很高的西方企业匹配。对于国内管理水平较差的企业而言选择这个系统的确有些超前了。慎重选择开发队伍。国内开发商的项目管理水平普遍较低所以实施大型项目没有太多经验拿客户开练。练完了人也走了白练。所以一旦选择实施大型项目对于实施队伍宁肯多花点钱也要请到优秀的队伍同时加强内部和外聘的监理。

新华书店总店的项目总结起来就是一句话一个陌生的队伍拿着一个陌生的软件到一个陌生的领域为一群陌生的对象服务。没有不失败的！

第三篇：失败案例总结ERP教训

失败案例总结ERP教训

时间：2010-04-29

来自：会计网

编辑：尛菁

ERP的管理思想和方法是以管理实践为基础的。ERP系统是对企业内部生产制造、工程技术、质量控制、财务、市场营销、服务维护、对竞争对手的监视管理等子系统的全面集成。鉴于ERP系统的思想、方法和所涉及的管理范围，企业上马ERP系统是大势所趋、成功实施ERP是众望所归。但企业在真正实施ERP过程中，并不是一帆风顺的或者很快就能达到理想目标的。有些企业在ERP方面进行了巨额的软硬件投资及人力投资并不能给企业带来预期的管理效益，陷入了一种不断投入却无法得到合理产出的投资漩涡。

下面，我们通过业界公知的ERP失败典型案例来剖析总结ERP失败的可能原因：

案例一：北京市三露厂在1998年3月20日与联想集成（后来划归到神州数码）签订了ERP实施合同。合同中联想集成承诺6个月内完成实施。ERP软件是联想集成独家代理瑞典Intentia公司。合作的双方，一方是化妆品行业的著名企业，1998年销售额超过7亿，有职工1200多人。一方是国内IT业领头羊的直属子公司。实施后存在一些表单无法正确生成等问题。后虽经再次的实施、修改和汉化，包括软件产品提供商Intenna公司也派人来三露厂解决了一些技术问题。但是由于汉化、报表生成等关键问题仍旧无法彻底解决，最终导致项目的失败。合作的结果是不欢而散，双方只得诉诸法律。

案例二：哈药案例。2000年，哈尔滨医药集团决定上ERP项目，参与软件争夺的两个主要对手是oracle与利玛。一开始，两家在ERP软件上打得难解难分，一年之后，Oracle击败利玛，哈药决定选择Orack的ERP软件。然而事情发展极具戏剧性的是，尽管软件选型已经确定，但是，为了争夺哈药实施ERP项目的“另一半”，2001年10月，利玛联手哈尔滨凯纳击败哈尔滨本地的一家公司华旭，成为哈药ERP项目实旌服务的“总包头”。但是，始料不及的是。到了2002年3月份，哈药ERP实施出现了更加戏剧性的变化。利玛在哈药ERP项目的实施团队全部离职。城门失火，殃及池鱼，整个哈药项目也被迫终止。而最近又有消息说哈药ERP项目又重新上马，真是一波三折。

案例三：许继项目被迫暂停。1998年初，河南许继集团采用symix公司（现更名Frontstep）的产品来实施ERP。从1998年初签单，到同年7月份，许继实施ERP的进展都很顺利。包括数据整理、业务流程重组，以及物料清单的建立都很顺利。厂商的售后服务工作也还算到位，基本完成了产品的知识转移。另外，在培养许继自己的二次开发队伍方面也做了一定的工作。如果这样发展下去，或许许继会成为国内成功实施ERP企业的典范。然而，计划赶不上变化。到了1998年8月份，许继内部为了适应市场变化，开始发生重大的机构调整。企业经营结构变了，而当时所用的ERP软件流程却已经定死了。于是许继与syIllix公司友好协商，项目暂停，虽然已经运行了5个月，但是继续运行显然已经失去了意义。symix的ERP现在只是在许继一些分公司的某一些功能上还在运行。

案例四：美国最大垃圾运输厂商Waste Management一纸诉状将全球知名的管理软件厂商德国SAP公司送上法庭。Wate Management公司花费了1亿美元安装的电脑系统理应发挥省钱的功效，但结果却是一次“彻底的失败”。Waste Management发言人Lynn Brown表示，公司已经控告出售这套系统的德国商用软件商SAP，要求退还所有相关费用，外加惩罚性赔偿。

2007年第四季净收益为3.09亿美元的Waste Management，尚未决定是否要为公司对这套系统的相关投资求偿。Brown在回信中表示：那要看SAP对这件官司的回应。我们必须评估他们的反应。SAP发言人Andy Kendzie拒绝评论此案。

SAP卖给Waste Management的电脑软件，应该是专门针对美国的废弃物处理公司所设计的产品，可帮助他们运送垃圾和处理资源回收，不需进一步的客制。根据美国SAP在2005年12月的新闻稿，这些软件处理的工作包括帐务、垃圾物流、装载容器管理和同步运算等。

诉状指出：“Waste Management并不知道，这套‘美国版’的废弃物与回收软件不成熟、未经测试且不健全。”该公司是在本月20日向所在地的德州地方法院提出控告。造成ERP项目失败的原因究竟是什么?

执行一个大型的ERP项目，其难度无异于攀登珠穆朗玛峰。许多无法逾越的障碍常常使得项目无疾而终。舆论认为大部分ERP项目的结果与预期的大相径庭。这些项目或者是不能达到可衡量的商业利益，或者更糟糕，有可能威胁到公司的经济实力。

把ERP项目与登山相类比是否有些夸张了?也许如此。但是它强调了ERP项目实施过程中存在的巨大障碍。正是这些障碍，在很大程度上使企业用ERP项目有效整合业务流程的愿望化为泡影，而最终换来的结果是昂贵的支出和心灰意冷。

1．ERP软件的选型失误

对于所有企业用户来说，从购买、选型，以及合同的签定，到后面的实施控制，大家都是没有经验的。比较专业的做法是，用户在购买前就应该知道自己到底需要什么样的东西。如果请厂商做分析的话，厂商往往从自己的产品角度去分析，把你引导到他现有的模式中去，这对客户是不公正的。为此，用户必须要请专业的公司或专家帮助分析需求。

很多企业由于在选型时期没有意识到ERP系统是为企业的发展战略和目标服务的，不清楚自己的需求，不了解软件的功能和厂商的实力；同样，技术专家没有按照企业的整体思路去设计并安装系统，而是出于完成系统上线或其它目的给企业提供了一套用非所需的系统，ERP系统很难取得成功的效益。企业在上ERP项目之前，必须要确定好自己想要达成的目标。再根据目标，提出符合实际情况的需求，做出全面地规划，而不能切不可以盲目地说上就上。

从三露的案例来说，三露的选型是失败的。可以说，首先，他们对自己的需求缺乏认识：上这个系统的目的是什么?这绝不是简单地把一些手工的工作搬到电脑里去。如果目的真这么简单，就不必买国外的软件。更深层次的原因是这个软件代表的管理思想是三露厂没办法接受的，比如它的财务管理系统和中国的财务要求有很大的差距。软件本身从技术角度来讲，永远都是可解决的，包括M0vEx这种产品从技术角度也是可以解决的。那为什么技术人员没解决问题?是因为这个技术解决方案和三露厂的管理要求是截然不同的东西。软件本身不可能失败，你想让我改到什么程度，我就能改到什么程度。但是这个软件本身所遵循的一种规律被破坏的话，它就回无力了。选型失误原因之二，他们没有很好地对MOvEx产品进行非常深入的了解，在当时来讲，在中国没有任何一个支持机构，而且没有本地化的强有力研发的支持团队。这种情况下，用他们的产品要想很有效地接近中国企业的需求，肯定会有问题。

选型失误之三，缺乏对企业发展战略的系统分析。许继集团在实施ERP不到半年的时间，就开始进行组织机构等管理环境的大调整，势必需要对信息系统进行再设计和再实施，其调整成本是巨大的，而且对软件的可扩展性要求非常高，symix否这个实力和功能暂且不谈，许继的失败更是由于其在选型阶段缺乏缜密的发展战略分析，导致信息系统在实施上马前就中途夭折，真是可惜！

2．ERP系统实施商的经验和实力不足

从三露案例来说，其失败的另一原因在于对实施商的选择。当时联想虽处于高速发展阶段，但它可能对管理软件的概念并不是很清晰，因为联想自身是做硬件系统集成的，人员可能也更多是做纯粹技术系统集成的。因此，他们没有想到做管理软件不是技术上的工程，而是一项复杂的管理工程，更多的应该是管理专家帮助企业去做这种实施的工作，而不是一些计算机人员。

3．ERP咨询顾问缺乏稳定性

ERP提供商和咨询公司由于自身也处于国内市场激烈的竞争之中，一旦受兼并或资产重组的影响，高层变动大，甚至带动一大批支持服务骨干“跳槽”，有的连咨询公司都不存在了。企业迎来一大批“新人”，工作重新做起，几次反复，严重打击企业的积极性。

“哈药”案例的主要原因是由于利玛在哈药ER_P项目的实施团队全部离职。城门失火，殃及池鱼，整个哈药项目也被迫终止。所以，在ERP选型的同时也包括对ERP实施商的慎重选择，必须对实施商的实施能力、资格、信誉等有全面的了解和掌握。

4．把“上线”作为项目的结束

ERP的实施绝不仅仅是一个简单的项目，“上线”并不是终点，而是一个新旅程的开始。一般来说，ERP项目的先期投资非常大，而期望的应用生命周期也在10—20年左右。企业组织起一个团队，用了15～30个月的时间终于完成了项目的“上线”，怎么能在投入使用的一个月后就散伙呢?保留ERP项目实施小组的主要人员——包括业务和技术人员，可以保障ERP的应用，处理应用中的瓶颈问题，改进系统，并且继续寻找提高生产力的方式。

5．缺乏综合能力强的项目负责人

由于ERP项目的实旌是一项系统工程，在实施过程中渗透性极强，涉及到工厂战略发展，生产，经营，产品开发，工艺，财务各部门，几乎覆盖了技术和管理的两大领域，ERP提供商及咨询服务公司派出的项目负责人的综合能力决定了该企业ERP前途和命运。如何高瞻远瞩地根据企业的现状及发展，制定好切实可行的ERP实施计划；如何发现并应对不合理的流程提出重组意见；如何与企业高层及时会话，促进企业的改革、改制、改组，提高企业的管理水平；如何督促咨询顾问，制定分步实施的目标任务，措施和绩效考核，每个模块的实施都向企业提供可操作的文档资料，这是ERP负责人的基本职责。但是，随着我国近几年掀起的ERP高潮，一些ERP厂商和咨询公司拿了不少订单，但如何组织实施，确保实施顾问的质量，就显得力不从心。由于项目负责人缺乏一定的能力和综合素质，导致项目走向失败或多走弯路的现象很多。

6．没有充分发挥整合信息的威力

ERP系统将一家企业的不同部门之间的不同职能如计划和日程安排、采购、生产、融资等的关键数据和沟通信息整合起来，而这种整合往往是跨地区、跨产品线、跨分销渠道、跨职能部门的。比如对一个产品制造商来讲，这样的一套系统可以显示目前库存有多少原材料，生产一个单位的产品要消耗多少成本，现在已经拿到了多少订单，等等。尽管ERP系统能够提供这么多的信息，实际中的疑问却是：我们需要这么多的信息吗?我们该如何利用这些信息?

三露厂的叹息，哈药的无奈，和许继的忧郁，都正在成为过去。但事情远没有结束。由于市场交换的复杂性日益增大、IT业的迅猛发展，使得企业管理和业务从来没有像现在这样依赖于技术，虽然信息化历程中潜伏着巨大风险，但我们没有理由因此而拒绝信息化的潮流，因此对信息化敬而远之。正如攀登珠峰一样，困难无所不在。但是ERP项目的成功给公司带来的甜头让人们对这个艰苦的旅程仍然充满期待。ERP系统是企业的支柱——无论是公司内部还是外部——从内部财务信息和业务表现数据的有效整合，到未来的延伸型企业和协同商务平台。这些是企业长远发展的根基。

我们现在所能做的是：尽量多地研究失败，吸取教训，并能从失败中找出一些实质原因，借鉴其经验与教训，指导我们未来的实践工作。例如，当原材料到达公司仓库并被扫描进入系统时，任何人都能获得此项信息并加以利用。当产品生产完成，被自动或手工输入系统时，就立即成为可销售的产品，员工不用等到第二天才获得这条信息。又例如，有了进入整合ERP主系统的网上通路，客户服务代表可以马上检索客户的历史记录及其他重要识别内容，还能够查阅在所有仓库(而不仅是当地仓库)的实时库存以及未来生产计划，根据客户需求在生产计划中冻结部分产品向该客户供应。实时整合和精确数据可以改变人们的工作。全新的ERP技术会影响

第四篇：ERP失败10大祸首

ERP失败10大祸首

造成ERP项目失败的祸首往往另有其人。

执行一个大型的ERP项目，其难度无异于攀登珠穆朗玛峰。许多无法逾越的障碍常常使得项目无疾而终。舆论认为大部分ERP项目的结果与预期的大相径庭。这些项目或者是不能达到可衡量的商业利益，或者更糟糕，有可能威胁到公司的经济实力。把ERP项目与登山相类比是否有些夸张了？也许如此。但是它强调了ERP项目实施过程中存在的巨大障碍。正是这些障碍，在很大程度上使企业用ERP项目有效整合业务流程的愿望化为泡影，而最终换来的结果是昂贵的支出和心灰意冷。尽管人们总是把问题归咎于技术的缺陷，但说实话，造成问题的祸首往往另有其人——比如应用ERP程序的人对系统的功能和运行一知半解。

诚然，正如攀登珠峰一样，困难无所不在。但是ERP项目的成功给公司带来的甜头让人们对这个艰苦的旅程仍然充满期待。ERP系统是企业的支柱——无论是公司内部还是外部——从内部财务信息和业务表现数据的有效整合，到未来的延伸型企业和协同商务平台。这些是企业长远发展的根基。

咨询公司通过多年实践摸索出来的经验教训，也许能提供一些有益的借鉴，帮助企业排除导致ERP项目失败的重重阻力。没有一本“ERP教科书”可以让每个项目完美无缺，但是听一听“老兵”的经验之谈是有百益而无一害的。下面按照严重性大小倒序列举ERP失败的10大祸首。

10.把“上线”作为项目的结束

ERP的实施绝不仅仅是一个简单的项目，“上线”并不是终点，而是一个新旅程的开始。一般来说，ERP项目的先期投资非常大，而期望的应用生命周期也在10～20年左右。企业组织起一个团队，用了15～30个月的时间终于完成了项目的“上线”，怎么能在投入使用的一个月后就散伙呢？

想像一下，一个历时3年、花费数百万美元所建成的大型化工厂，在开工不久就把他们的工程师们遣散回家。这是不可能的！在未来的岁月里，工厂还要仰仗这些工程师来不断发展。保留ERP项目实施小组的主要人员——包括业务和技术人员，可以保障ERP的应用，处理应用中的瓶颈问题，改进系统，并且继续寻找提高生产力的方式。9.对系统启用后暂时的低潮表现缺乏心理准备

大部分ERP项目对企业构架的改变是革命性的，有时候企业一半以上的后台交易系统被替代，从而影响到90%的业务流量。这不仅仅是技术转型，它很大程度上改变了一个企业的业务流程、企业文化、企业知识以及工作环境。因此，项目上线后随之而来的适应期是不可避免的。研究表明，甚至那些在实施阶段非常顺利的项目，也无法避免新系统启动后的适应期。例如，交易处理效率可能从98%下降到90%，处理销售订单或者货品入库的速度都有可能减慢。

企业必须通过详细计划、试点试用、内部教育和风险分析等一系列手段，来减少这种情况发生的可能性。但是，企业必须充分认识到项目上线最初的这段适应期的存在。如果执行得当，那么这种负效果可以减低到最小，而且在最短的时间内消除。

8.难以平衡业务整合需要和对短期绩效的追求

如今，每个CEO都必须尽快做出成绩来，而不是在一年半载之后。由于一个完整的ERP项目实施所面临的巨大挑战，他们很难向董事会承诺，ERP项目实施后的2～3年内可能节省的具体费用，他们要的是即时的回报。

由此而言，ERP项目实施面临的挑战是：如何规划好项目的规模和实施顺序，从而迅速地获得最大程度的商业回报，同时不危及ERP整合的最佳效果。

7.与数据有关的各项工作启动太晚

数据的一致性和准确性至关重要。ERP项目的投资巨大，但要记住的是：系统的有效使用依赖于原始输入数据的准确性。问题往往就出在这里。调查显示，绝大部分公司在意识到数据的质量和准确度时都为时已晚。

在项目刚开始时就应该考虑数据的问题，而不要留到系统上线的前2个月才如梦初醒。要决定采用何种新的数据标准，清理和转移现有数据也需要大量的时间。这将保证有关客户、供应商和账目的重要信息与未来的业务发展保持一致。

举例来说，供应商对客户的采购情况比客户自己更清楚，这种情况毫不让人感到意外。假设你从一家主要的化工厂商那里购买产品和服务，而这家厂商在32个国家为你提供服务。如果这是一家运作良好的厂商，那么他们对你的全球购买情况很可能比你自己还要清楚。而ERP的实施可以从技术上让你占据上风，由此去争取更多的折扣。但是，只有当系统中的数据前后一致并及时更新，并且你能够即时获得这些数据时，才可能争取价格优势。

6.“核心团队”缺乏顶尖业务人员和技术人员

这可能成为一个巨大的挑战。你的项目需要顶尖高手的参与——不仅仅是技术明星，更需要业务好手。即使你必须牺牲某方面的质量，也不能放弃业务尖子。相反，也许你可以牺牲技术专才，因为你保留的咨询顾问可以带来熟练的技术人员。

这些高手应该比任何团队中的其他成员更紧密地围绕在项目经理周围，千万不要因为张三或李四无所事事而将他们纳入团队中。这样做可能很困难，因为你最好的下属无疑正忙于其他事务，而有些大型的ERP项目需要200～300人的参与。可是，你必须将你最好的一些队员从日常事务中解放出来，加入ERP项目组。5．项目起步了，却没有高级管理小组的支持

任何一个大型ERP项目都会牵扯庞杂的业务流程、角色、职责、标准以及数据定义，而这些变革无法自下而上地开展。一个有效的管理小组就显得格外重要，而一位高级行政人员进行积极有效地领导也同样关

ERP项目会触发一些困难的、有时甚至是恶性的问题，而承担责任的这位高级管理人员就可以及时处置，并观察指挥部是否能够理解并接受这些决定。

管理小组可以每个月碰头一个小时，勉励项目经理，或者也可以花更多的时间了解和指导项目进程，做出重要的决定，规划公司的未来。两者之间有天壤之别。

从业务角度来看，这位高级管理人员通常会是首席财务官，也可以是首席行政官，尤其是那些涉及关键的业务转型、并且关乎公司未来的成功的项目。如果ERP项目影响到销售及分销，那么牵头的就应该是销售及市场副总裁。ERP项目的“守护神”必须是集团领导层的一员，并且最好不是首席信息官。除非CIO同时还是一个出色的业务经理，并能影响其他的高级业务管理人员。否则，其他的管理人员不会积极参与，而ERP项目则会变成CIO和他的技术人员的任务。4．忽视强有力的系统整合团队的建议

公司经常花费大量的时间和金钱选择一个强有力的系统整合团队（System Integrator，SI），却在项目进程中处处与之为敌，这实在让人匪夷所思。如果总是质疑SI，或者认为它的建议只是为了简单地产生更多收入，那为什么还要为了咨询顾问的专才花费巨资呢？SI应该成为你的左膀右臂，因为ERP对你而言有可能只是第一次或者第二次接触，而SI也许已经数十次或者上百次经历过类似案例。那么为什么还要对SI百般猜疑呢？

相互尊重和伙伴关系是项目成功的关键，包括对每一位伙伴以及软件供应商的尊重。同样，SI也不能先入为主地认为客户百般刁难而不愿提供有力的咨询意见。

在选择SI时，公司应该：

首先，考虑兼容性。你是希望咨询公司从天而降替你完成所有工作，还是和你携手工作解决困难呢？有些SI公司偏好“携手合作”的态度，而其他公司则喜欢对你说：“这是给你的指令，这是未来的景象，我们开始工作吧。”

其次，你可以根据公司文化决定选用哪种工作方式。

再次，仔细审查SI的工作记录。除去SI的包装，和软件供应商以及业内分析人士交流，听取他们的意见。

最后，花时间考察将与你并肩工作的每一位团队成员，记住在合同中规定，在项目进行过程中，项目领导和伙伴应始终在你左右。

3．试图创造与公司文化不相容的解决方案

20世纪90年代，调研发现，许多进行ERP项目的公司都视之为排除万难的灵丹妙药——即使解决方案的“风格”与公司的文化传统并不相容。

管理人员也许希望在一个全球业务中央集权式的环境中工作。和沃尔玛颇为相似，全球总部拥有不可置疑的权力和纪律。然而，如果公司的文化崇尚分权式的创业精神，那么沃尔玛式的风格并不适合。你无法运用技术强行改变公司的文化，因此如果公司的结构十分离散，那最好选择安装分权式的ERP应用程序，或者直面将要来临的巨大变革。

假如你准备将93个仓库合并成5个或者6个，并“指望”ERP程序帮你完成。从技术上来讲，ERP能够做到。但这不是一个简单的技术流程，而是业务/人员流程。如果没有人改变态度，整个公司不理解也不支持这样的合并，你的项目将付诸东流。但是，假如CEO授权某人彻底审视整个公司及其文化，那就另当别论了。需要重申的是，CEO并不将ERP视为简单的技术解决方案，而同时也是业务和组织解决方案。CEO应该从一级和二级经理中挑选合适的人选，在全新的制度下工作，并使ERP项目大获成功。

2．没有充分发挥全新的整合信息的威力

请不要误解，ERP技术是切实可行的，但ERP项目30%的挑战来自技术层面，而剩余的70%则来自人员和流程。很少会有人由衷地喜欢变革，然而当公司转向实施SAP时，变革无法避免。小而言之，员工的电脑屏幕会发生变化；大而言之，员工的整个生活都会改变。

新兴技术统摄一切，并且，一般来说，能使信息随手可得。例如，当原材料到达公司仓库并被扫描进入系统时，任何人都能获得此项信息并加以利用。当产品生产完成，被自动或手工输入系统时，就立即成为可销售的产品，员工不用等到第二天才获得这条信息。

实时整合和精确数据改变了人们的工作。一个传统的订单操作员可以成为全能的客户服务代表。例如，有了进入整合ERP主系统的网上通路，客户服务代表可以马上检索客户的历史记录及其他重要识别内容，还能够查阅在所有仓库（而不仅是当地仓库）的实时库存以及未来生产计划，根据客户需求在生产计划中冻结部分产品向该客户供应。全新的ERP技术会影响许多人员，他们需要培训以掌握流程。1．ERP商业计划没有生命力

毫无疑问，ERP项目通常需要12～36个月的时间才能付诸实施，而且通常耗资500万～5000万美元不等，持续能力至关重要。所以，你必须确认开展ERP项目的理由，即准备一个扎实的商业计划。

另一方面，如果没有一个实实在在的商业计划，你不可能得到整个业务小组的支持。很多时候，一个企业实施ERP项目并不仅仅是为了减少技术成本，因为ERP实施后总的技术成本往往会明显上升。ERP项目的实施常常是出于更宽泛的业务目的，如果大家对项目实施的目的一知半解，而且没有事先获得对项目内容和投入资金的批准，就不可能得到高级管理层的全力支持。5年前，虽然有一些大公司为ERP项目做了商业计划，提交拨款申请，然而，一旦计划核准，项目开始启动，这些计划即被束之高阁。与5年前相比，现在的情况大有改进。

一个ERP商业计划是具有生命力的，并且随着项目的进行而不断地更新。它应该设定如何去跟踪ERP应用所带来的效益。它必须为CEO提供参考，把成本降低和收益增长分列到公司每年的运营预算中去，并以此作为每个副总的业绩指标。它必须明确中高层的管理人员对达成目标担负相应的责任，以保证实现预期的底线利益。这种做法现在还相当少，部分原因是许多管理人员都会有“在项目结束时，我可能早就不在这里工作了”这样的想法。

仅有技术是不可能帮助你达成商业目标的。ERP项目的成功离不开一个设计周全、久经考验的商业计划。那么商业计划究竟有多重要？我们认为，它的重要程度足以让它列为10大之首。回想1953年举世瞩目的那一天，新西兰人埃德蒙·希拉里爵士和尼泊尔人登津·诺尔盖成功地登上了珠穆朗玛峰，成为世界最高峰的第一批造访者。他们的成功是否给了你灵感和启示？他们登上顶峰靠的不是新奇的技术，他们的装备其实相当简陋。他们之所以成功是因为他们从登山先驱们的失败中学到了如何成功避免致命的错误。成功地实施ERP项目也许无法与登上世界第一高峰相提并论，但它的失败会给公司的业务带来可怕的打击。请学会避免以上的10个错误，使你的ERP项目一路顺风。

第五篇：历年来ERP著名失败案例深度解析

在一些ERP论坛里，有人想找理想的ERP系统。在众多的建议中，一般会出现这样的回应：

“在预算范围内，要挑最贵的，最有名的，这样大家都不用承担责任。比如上SAP，如果有个三长两短，谁也不好说什么：世界一流的产品你没用好，你说是谁的原因？”

如果用英语称这类的说法用语为“FUD”。即：Fear、Uncertainty、Doubt。翻译出来就是：如果你敢去建议你的上级去买别家的软件和服务、不买我的，那么，你这个软件采购决策者，也就是CIO的职位难保！

这类的恐吓，对于大量“不具IT专业、职业道德却有瑕疵”的IT决策者的确具有强大的影响力。

上文中做建议的这位“ERP专家”所指的“世界一流的产品”，不是什么神丹妙药，而是数个利益团体在造神运动中所捏造出来的神话。

一句“世界500强都在用”的广告语远远不足以反应实情。自制的市场调查统计没有揭露的是：有哪些流程模块在这些企业运行？是不是只有进销存、或者甚至只有所谓“FI”的会计模块在跑？

出现太多泡沫的时候，应早日戳破，以免为期过晚。下面是笔者整理的一些知名ERP失败案例，希望能对从事相关工作的CIO朋友有所启发：

Intenna和北京三露厂的合作案例

北京市三露厂在1998年3月20日与联想集成（后来划归到神州数码）签订了ERP实施合同。合同中联想集成承诺6个月内完成实施。ERP软件是联想集成独家代理瑞典Intentia公司。合作的双方，一方是化妆品行业的著名企业，1998年销售额超过7亿，有职工1200多人。一方是国内IT业领头羊的直属子公司。实施后存在一些表单无法正确生成等问题。后虽经再次的实施、修改和汉化，包括软件产品提供商Intenna公司也派人来三露厂解决了一些技术问题。但是由于汉化、报表生成等关键问题仍旧无法彻底解决，最终导致项目的失败。合作的结果是不欢而散，双方只得诉诸法律。

ERP软件流程定死导致许继项目失利

许继项目被迫暂停。1998年初，河南许继集团采用symix公司（现更名Frontstep）的产品来实施ERP。从1998年初签单，到同年7月份，许继实施ERP的进展都很顺利。包括数据整理、业务流程重组，以及物料清单的建立都很顺利。厂商的售后服务工作也还算到位，基本完成了产品的知识转移。另外，在培养许继自己的二次开发队伍方面也做了一定的工作。如果这样发展下去，或许许继会成为国内成功实施ERP企业的典范。然而，计划赶不上变化。到了1998年8月份，许继内部为了适应市场变化，开始发生重大的机构调整。企业经营结构变了，而当时所用的ERP软件流程却已经定死了。于是许继与syIllix公司友好协商，项目暂停，虽然已经运行了5个月，但是继续运行显然已经失去了意义。symix的ERP现在只是在许继一些分公司的某一些功能上还在运行。

Oracle和哈尔滨制药的合作案例

2002年首次在中国举行的Oracle全球电子商务和新技术大会上(OracleWorld)，Oracle董事长兼CEO拉里·埃里森意外遭遇一位国内用户的“挑战”。一位来自哈尔滨医药集团(以下简称“哈药”)的ERP用户代表当场质问埃里森，哈药购买了Oracle的ERP系统之后，在实施中遇到了很大的麻烦，作为软件供应商，Oracle如何管理其合作伙伴(ERP实施服务提供商)？

对于这一突如其来的提问，埃里森没有正面回应。事后，一位Oracle(中国)公司高级经理就此解释说：没错，哈药是购买了Oracle的ERP系统，但是Oracle只是向哈药销售了软件产品，哈药在实施过程中遇到的问题和Oracle产品没有关系，而且这些问题是由于“不可抗力”引起的——负责哈药ERP实施的北京利玛信息技术有限公司(以下简称“利玛”)突然爆发人事变动，直接导致项目实施中止。

来自哈药方面的最新消息表明，哈药将重新启动ERP项目，并在第二次选择实施伙伴上采取谨慎的策略，而在此次决定之前，哈药要求4家新入围的咨询服务公司，对哈药相关人员分别进行ERP培训，并且拿出各自的实施方案来参与最终的角逐。

英国ICI因使用SAP而损失2300万英磅

英国ICI由于一个失败的SAP供应链软件的实施，损失了2300万英镑。ICI的发言人表示，公司第一个财年亏损了1800万英镑，下一个财年将会损失500万英镑。

导致亏损的直接原因是知名的Q-Star项目——一个基于SAP供应链软件的项目。在2002年5月底，该系统在原材料从荷兰发往4个地点发生了定位问题，从而生成大量积压待处理的订单。造成了不小损失。ICI曾希望Q-Star将在2004年节省2000万英镑。但一切都付之东流。

耐克采用i2的后果：损失金额＝8000万～1亿美元 i2公司与耐克公司在2001年的合作纠纷：耐克公司在2001年第三季度销售损失8000万美元到1亿美元，耐克认为是由于i2的软件存在订单管理漏洞。耐克公司表示，自前一年夏天采用i2-powered系统之后，一些鞋的订单结束了两次，一次通过新的制度的管理系统，一次是旧的订单管理系统。

但i2认为耐克没有按照i2的建议，最大限度地减少定制，以用于鞋类和服装业务的最佳做法，并分阶段部署系统。耐克公司的软件和大量定制了一次活动涉及到数以千计的供应商和分销商。

“如果我们的部署是为他们创造了一个商业问题，为什么我们从来没有通知？”耐克发言人没有就这一问题发表评论。

谁真正犯错？耐克的项目一开始只不过才一年多。Gartner的分析师认为不能单纯将责任归咎于一方，最终的成功取决于合作。

遗憾的是，对于上列失败案例，即使是外国的所谓ERP专家，都避而不谈其失败的主要原因：ERP软件的品质不良。其检讨文章永远围绕在“用户的操作流程一变再变、预算要越多越安全、项目管理技巧要登峰造极、老板的支持不足、用户的管理水平低下。”之类的老生常谈，“用户的操作流程与世界前500强的行业标准不符”更是商人在ERP项目失败后，和用户的CIO联手掩饰不成功主要原因时的经典借口。

综上，笔者认为，品质好的ERP软件，除了满足基本的功能需求之外，还必须符合“软件应用简单、柔性扩展方便、易实施、易维护、易上线等”必要条件。另外，通过以上业界公知的ERP失败典型案例还可以发现ERP失败的诸多因素：

1．ERP软件的选型失误

对于所有企业用户来说，从购买、选型，以及合同的签定，到后面的实施控制，大多都是没有经验的。比较专业的做法是，用户在购买前就应该知道自己到底需要什么样的东西。如果请厂商做分析的话，厂商往往从自己的产品角度去分析，把你引导到他现有的模式中去，这对客户是不公正的。为此，用户必须要请专业的公司或专家帮助分析需求。

很多企业由于在选型时期没有意识到ERP系统是为企业的发展战略和目标服务的，不清楚自己的需求，不了解软件的功能和厂商的实力；同样，技术专家没有按照企业的整体思路去设计并安装系统，而是出于完成系统上线或其它目的给企业提供了一套用非所需的系统，ERP系统很难取得成功的效益。企业在上ERP项目之前，必须要确定好自己想要达成的目标。再根据目标，提出符合实际情况的需求，做出全面地规划，而不能切不可以盲目地说上就上。从三露的案例来说，三露的选型是失败的。可以说，首先，他们对自己的需求缺乏认识：上这个系统的目的是什么?这绝不是简单地把一些手工的工作搬到电脑里去。如果目的真这么简单，就不必买国外的软件。更深层次的原因是这个软件代表的管理思想是三露厂没办法接受的，比如它的财务管理系统和中国的财务要求有很大的差距。软件本身从技术角度来讲，永远都是可解决的，包括M0vEx这种产品从技术角度也是可以解决的。那为什么技术人员没解决问题?是因为这个技术解决方案和三露厂的管理要求是截然不同的东西。软件本身不可能失败，你想让我改到什么程度，我就能改到什么程度。但是这个软件本身所遵循的一种规律被破坏的话，它就回无力了。选型失误原因之二，他们没有很好地对MOvEx产品进行非常深入的了解，在当时来讲，在中国没有任何一个支持机构，而且没有本地化的强有力研发的支持团队。这种情况下，用他们的产品要想很有效地接近中国企业的需求，肯定会有问题。

选型失误之三，缺乏对企业发展战略的系统分析。许继集团在实施ERP不到半年的时间，就开始进行组织机构等管理环境的大调整，势必需要对信息系统进行再设计和再实施，其调整成本是巨大的，而且对软件的可扩展性要求非常高，symix否这个实力和功能暂且不谈，许继的失败更是由于其在选型阶段缺乏缜密的发展战略分析，导致信息系统在实施上马前就中途夭折，实在可惜！

2．ERP系统实施商的经验和实力不足

从三露案例来说，其失败的另一原因在于对实施商的选择。当时联想虽处于高速发展阶段，但它可能对管理软件的概念并不是很清晰，因为联想自身是做硬件系统集成的，人员可能也更多是做纯粹技术系统集成的。因此，他们没有想到做管理软件不是技术上的工程，而是一项复杂的管理工程，更多的应该是管理专家帮助企业去做这种实施的工作，而不是一些计算机人员。

3．ERP咨询顾问缺乏稳定性

ERP提供商和咨询公司由于自身也处于国内市场激烈的竞争之中，一旦受兼并或资产重组的影响，高层变动大，甚至带动一大批支持服务骨干“跳槽”，有的连咨询公司都不存在了。企业迎来一大批“新人”，工作重新做起，几次反复，严重打击企业的积极性。

“哈药”案例的主要原因是由于利玛在哈药ERP项目的实施团队全部离职。城门失火，殃及池鱼，整个哈药项目也被迫终止。所以，在ERP选型的同时也包括对ERP实施商的慎重选择，必须对实施商的实施能力、资格、信誉等有全面的了解和掌握。

4．把“上线”作为项目的结束

ERP的实施绝不仅仅是一个简单的项目，“上线”并不是终点，而是一个新旅程的开始。一般来说，ERP项目的先期投资非常大，而期望的应用生命周期也在10—20年左右。企业组织起一个团队，用了15～30个月的时间终于完成了项目的“上线”，怎么能在投入使用的一个月后就散伙呢?保留ERP项目实施小组的主要人员——包括业务和技术人员，可以保障ERP的应用，处理应用中的瓶颈问题，改进系统，并且继续寻找提高生产力的方式。

5．缺乏综合能力强的项目负责人

由于ERP项目的实旌是一项系统工程，在实施过程中渗透性极强，涉及到工厂战略发展，生产，经营，产品开发，工艺，财务各部门，几乎覆盖了技术和管理的两大领域，ERP提供商及咨询服务公司派出的项目负责人的综合能力决定了该企业ERP前途和命运。如何高瞻远瞩地根据企业的现状及发展，制定好切实可行的ERP实施计划；如何发现并应对不合理的流程提出重组意见；如何与企业高层及时会话，促进企业的改革、改制、改组，提高企业的管理水平；如何督促咨询顾问，制定分步实施的目标任务，措施和绩效考核，每个模块的实施都向企业提供可操作的文档资料，这是ERP负责人的基本职责。但是，随着我国近几年掀起的ERP高潮，一些ERP厂商和咨询公司拿了不少订单，但如何组织实施，确保实施顾问的质量，就显得力不从心。由于项目负责人缺乏一定的能力和综合素质，导致项目走向失败或多走弯路的现象很多。

6．没有充分发挥整合信息的威力

ERP系统将一家企业的不同部门之间的不同职能如计划和日程安排、采购、生产、融资等的关键数据和沟通信息整合起来，而这种整合往往是跨地区、跨产品线、跨分销渠道、跨职能部门的。比如对一个产品制造商来讲，这样的一套系统可以显示目前库存有多少原材料，生产一个单位的产品要消耗多少成本，现在已经拿到了多少订单，等等。尽管ERP系统能够提供这么多的信息，实际中的疑问却是：我们需要这么多的信息吗?我们该如何利用这些信息?

三露厂的叹息，哈药的无奈，和许继的忧郁，都正在成为过去。但事情远没有结束。由于市场交换的复杂性日益增大、IT业的迅猛发展，使得企业管理和业务从来没有像现在这样依赖于技术，虽然信息化历程中潜伏着巨大风险，但我们没有理由因此而拒绝信息化的潮流，因此对信息化敬而远之。我们现在所能做的是：尽量多地研究失败，吸取教训，并能从失败中找出一些实质原因，借鉴其经验与教训，指导我们未来的实践工作。例如，当原材料到达公司仓库并被扫描进入系统时，任何人都能获得此项信息并加以利用。当产品生产完成，被自动或手工输入系统时，就立即成为可销售的产品，员工不用等到第二天才获得这条信息。又例如，有了进入整合ERP主系统的网上通路，客户服务代表可以马上检索客户的历史记录及其他重要识别内容，还能够查阅在所有仓库(而不仅是当地仓库)的实时库存以及未来生产计划，根据客户需求在生产计划中冻结部分产品向该客户供应。实时整合和精确数据可以改变人们的工作。全新的ERP技术会影响许多人员，但他们需要培训以掌握流程。如果信息不能被有效地加以利用，发挥整合的威力，那么信息化的效益也没法凸现，更可能人们工作成为信息的奴隶。