最近在重庆客串一家中型制造业企业的CIO，帮助该企业制定信息化战略规划，并直接参与PDM和ERP系统的实施工作。由于以前一直充当乙方，这次可是客串了一回甲方。哈哈。挺有意思。准备给自己找个麻烦，将实施过程中的体会随手写一些供大家分享。具体写成什么样也没有计划，只是准备胡乱写写。供大家一笑。
该企业和国内著名的ERP开发商（照顾到该企业的面子就不提具体的名字了）合同签了两个月了，实施工作一直开展的不顺利，进度极为缓慢。老板甚为恼火。因此邀请我这个外行客串CIO，帮助实施ERP。
物流企业的信息化本人实战经验比较多了，但是制造业企业的ERP实施可是新媳妇上轿头一回。由于离开制造业已经多年，对于现代制造业的很多东西都已经不懂了，因此感觉有点心虚，但是一想到能客串一回甲方，并且能学到很多新的东西，又有盛情邀请，就厚着脸皮客串这一回了。
过来以后，不敢贸然充大，抱着虚心学习的态度，认真从学生做起，保留原项目实施小组的成员和项目负责人原封不变，老老实实的充当组员，从头学起。
参加了两次项目小组的例会，发现开发商的实施顾问一肚子怨气，总是抱怨实施进度缓慢，计划总是拖延。并指责我们企业执行力太差！
不过既然充当CIO还是要负点责任的。因此分别与老总和几位副总进行了沟通，话题只有一个：“你希望ERP能为我们解决什么问题?”。本以为这个问题问的有点初级，可是没曾想，竟然的不到一个明确的答案。和每个人沟通后的感觉就像瞎子摸象，每个人的回答都不一样，并且我这个老手竟然归纳不出一个整体的轮廓来。真是出乎我的意外。
经过一周多的观察后，发现问题的真正原因在于实施顾问根本没有进行深入的调研，对企业的真实需求了解不够，因此各个部门和高层领导对ERP的了解都是一知半解，并且实施顾问没有与有关部门进行正确的沟通。企业的高层中的主管副总虽然能明确表达对ERP实施结果的期望，但是也不知道应该如何推动项目的实施。
回想起来，恐怕大多数的企业，在信息化过程中都有类似的共性问题。虽然都号称“一把手工程”，但是实施顾问的能力和层次无法与企业高层进行正确的沟通，并且也不敢直接面对企业的高层领导。实施结果就是给员工培训一下以后草草了事。这样做的结果可想而知。
据开发商介绍，由于软件已经非常成熟，因此软件装上服务器以后，应支付后续款项。我一算如果按合同付款，我们已经支付了项目全款的75%，可是到现在到底卖的是什么东西，除了一张光盘和几张流程图以外，什么都没有呢。这个风险太大了。因此我行使权力明确告诉对方：暂时拒绝继续付款。
这下可把对方的区域经理给逼急了。一再要求与我面谈，无奈之下，只好充当一回恶人了。
由于有多个项目实施成功的经验，因此明确指出对方在实施过程中的一系问题后，对方心服口服的承认，他们的实施方法虽然符合公司的一贯做法，但是确实存在我指出的问题，愿意全面接受我提出的实施交流方案。
经过最近两周与各部门的的深入沟通：首先让各部门都明确的自己的工作内容和软件的操作方法（说实话对ERP的流程和可操作性实在不敢恭维）。找出了很多跨部门责任不清的问题。经过组织跨部门的会议，将工作职责逐步理清。
结果：
目前项目进度按时完成。再也没有出现延误的情况。
各个部门的数据准备工作，也不用项目小组成员督促了。
ERP的实施工作逐步进入大家的讨论话题，甚至有些部门已经期待系统尽快实施。
ERP的管理思想逐步得到了大家的理解。因此项目实施结果基本可以预期。
小结：
在项目实施前期，与用户的深入沟通十分必要，不但可以让开发商正确进行方案配置，并可有效的调动了各部门的实施积极性。
我的初步感觉，由于该公司是国内最著名的ERP开发企业之一，应该代表了国内ERP的主流水平。ERP软件，无论从管理思想、易用性和流程管理方面亟待加强。
对于ERP为什么成功率低，企业实施见效慢有了一些不太成熟的看法。

ERP实施中需要考虑的其他问题：

信息中心团队的建设：

根据我几年来的经验，信息化实施过程和使用过程中，网络、服务器和客户端的稳定性直接影响到企业的正常运作。随着信息化水平的不断提高，对这三个方面的依赖性会越来越高，一旦出现重大问题后果不堪设想。

因此信息中心队伍的建设是保证系统正常运行的前提条件之一。由于这个企业本身是以技术研发为导向的企业，大量采用计算机辅助设计，并且有MIS、物流管理和OA系统，由于各个系统互相独立，并分布于不同的服务器上，一个系统的瘫痪对整个企业的影响还不至于造成重大影响。但是一旦通过PDM和ERP将设计制造都连成一个统一的系统，那么一旦出现问题，将对企业的各个方面造成重大影响。

经与信息中心每个员工的深入交流，发现现有员工技术水平还是不错的。局域网运行多年来，未发生过严重的问题。但是由于企业高层重视程度不够，加上有关制度不到位，信息化中心经常遭到个方面的投诉，因此信息中心的员工积极性不高，如果不能调整现有员工的心态，提高技术水平，将很难适应PDM和ERP实施后出现的新情况。


另外根据实施其他企业的经验，信息系统上线只是问题的开始，如何让ERP产生效益，信息中心将担负着重大的责任。如何有效的推动系统有效的应用，帮助企业改变手工作业的习惯，特别是改变旧的思维模式以适应新的信息化的管理。信息中心将担负着重要的责任。

原来做乙方时经常考虑这个问题，可是看着用户的高层往往是实施完成后，就认为是操作人员日常工作了，对如何利用好信息化这个工具普遍重视不足，因此信息化并没有给企业带来更大的效益。原来做为开发商，看着这种情况干着急根本使不上劲！现在客串一回甲方，看看能不能找到解决问题的方法。这也是一种难得的体验。哈哈。


因此如何有效的提高大家的积极性，激发大家的学习和工作热情，恐怕是需要重点解决的问题之一。
如果能逐步带出一个有战斗力的团队，对于信息化的取得成功将是有利的保障。

如何避免IT黑洞：

信息化中除了应用软件投资以外，与之相配套的服务器、防火墙、操作系统、数据库软件、杀毒软件，以及为了适应C/S架构的ERP的需要，还要对客户端的PC进行全面的升级。这几项投资在原有的预算中根本没有考虑。如何有效控制投资避免出现IT黑洞，也是一个必须面对的问题。

由于公司要求逐步实现软件正版化，看来操作系统和配套软件的投资将是一个不小的投入。

如果能够在PDM和ERP选型时注意这个问题，选择在其他平台下开发的信息系统，也许会节省一笔不小的投资。

是这样，在ERP的实施过程中，开发商有一个分阶段推进的计划，从表面上来看还是很完整的。但是忽略了一个问题，实施过程中各部门之间的协调和配合是要企业的高层进行统筹的。

他们原来的实施方法，主要是与各个部门进行沟通。忽略了与企业高层的沟通与协调。因此与各部门沟通过程中出现的问题，很难得到有效的解决。

另外还有一个问题，由于实施顾问认为他们的系统已经比较成熟，习惯性的认为与各部门沟通清楚后，对软件进行设置，定制出作业流程。然后在培训中验证流程的合理性。但是由于各部门根本无法了解系统的业务流程，并且不知道自己操作的界面会是什么样子。以空对空的进行交流，不但效率低，并且很难调动起大家的兴趣。

改进的方法：首先和企业的高层领导开了一个方案介绍会，听取我们企业高层对ERP实施结果的真实想法。在此基础上，初步设计出系统的工作流程。

重新组织各部门按流程图并结合软件界面进行深入沟通，认真听取各部门反馈的意见和建议。如果是合理的建议，调整流程图，并得到认可，如果是不太合理的要求（其实这种情况经常发生），通过沟通让使用者理解系统的设计思路，实在不行我就行使权力，明确指出这个问题不需要在系统中做出修改。跨部门的问题进行汇总后，上报企业高层，并与高层进行沟通，争取得到支持。


其实说白了，就是前期沟通越到位，后期实施越容易。这一点经常被开发商忽略。

经过几周来的调整，目前项目进度基本正常。之所以说基本正常是由于PDM的数据准备没有完全做好，由于是两个开发商，因此发现问题后需要PDM开发商配合，因此今天看来本周的工作进度要延误3天了。

信息化实施过程中还有一个重要的问题，就是客户端的硬件、软件和原有操作人员的工作习惯，是否能够适应新系统的问题。

由于原来都是采用电子表格等单机版的程序，因此对客户端的要求不是很高。但是一旦联网并按流程运行，必须要保证客户端能够跟上，否则整个流程都会受到影响。

本周让信息中心的系统管理员，重新起草了网络安全规定，要求有关规定必须能够被人理解、可以量化，并且可执行。

原来的所谓规定竟然长达17-18页，好像面面俱到，可是根本没人看，并且很多规定好像很严谨，但是根本无法执行。

我要求系统管理员拿出10条左右的具体规定，看似简单的问题，竟然修改了3稿。仔细想想，越是简单的、可执行、可量化的规定越难写。今天终于交稿，让办公室下发。这次的规定非常明确，完全针对现在网络中经常发生的一些问题。并且有明确的警告和处罚方法。

最高兴的是，教会了系统管理员如何编写有关的制度。以后就只管审阅了就行了。

仔细想想很多单位的制度都存在类似的问题，看似制度非常完善，仔细推敲会发现很多条款很难理解，根本无法考核，并且一上来就是罚款，看到制度的人心理就不买账，并且由于谁都不愿意得罪人，这样的制度往往得不到有效的执行。

这几周一直在想几个问题，信息化过程中什么最关键？

是软件的功能越完善越好，还是适用够用最好？

是软件选型重要，还是正确实施，并坚持使用下去重要。

今天和实施顾问探讨，经过一周的深入交流，这套ERP满足我们需求的百分比大概是多少？

他看了看我，犹豫了一下，回答道：估价修改和调整后能达到70-80%。

这样的满足率实施后是否能称为成功的项目呢？看来信息化任重而道远！

还有一个小插曲，上周例会前，项目小组成员将每次的沟通纪要整理了一遍，将各部门提出的要求进行了汇总，并明确向开发商提出修改意见。

在方案讨论中，制作部和财务部都提出的要对设备产能进行管理，以便让车间管理更加完善，并且有利于财务对在制品的成本能有效进行核算。开发商明确回答无法满足。并且指出这个问题非常复杂，就是开发出来实用性也不大。

从理论上讲，这个要求很合理，但是是否真的合理我没有把握。

带着这个问题，与生产总监进行了探讨，经讨论后生产总监认为：由于以后将按JIT方式进行生产过程改造，这个功能意义不大。

经过沟通后，生产总监主动承担和财务、制造两个部门进行沟通。取消开发这个功能的要求。

今天得到反馈，已经达成有关部门已经达成共识，不必开发这个功能。真让我松了一口气。真要感谢生产总监，我的能力根本无法决策到底应该怎么做。

果然不出所料，由于PDM数据准备出现问题，项目进度延误3天。不过由于各部门配合协调能力增强，看来后面能追回进度。

周例会开了25分钟，大家都比较满意。提出的几个重要问题，已经有人自动承担落实和协调的责任。原来这类问题要开会时强调，并落实到人和具体完成时间。今天开始发生变化，可喜！要是这样保持下去，越往后实施队伍就越得力。成功的保证基础就有了。

看来不是人们不知道应该做什么，也不是不愿意做，如何没有调动起大家的积极性，什么都要安排，并且督促才能完成。

还有一件高兴的事，由于ERP是C/S结构，对客户端的要求比较高，因此原有的好多PC是C3或P3的机器，内存太少只有128兆，ERP客户端根本跑不起来。一统计要换掉46台机器，有点麻烦。投资有点大，今天系统管理员和实施顾问沟通后，想出了一个好办法，调整一下其他服务器，腾出一台服务器，用远程登录的方法进行报表的查询。这样对客户端的要求就没有特殊的要求了。能节约不少投资呢。真不错！！

记得刚过来时，系统管理员一直在抱着观望的态度，明显感觉有点敌对情绪。经过多次沟通，已经能狠好的配合工作了。

明天信息中心自觉加班，重新调整整个办公大楼的网络布线和修复坏掉的模块，这可是个重活。本想以后再说，大家今天主动提出加班。好好表扬了一下。呵呵。

今天都是好消息。不过肯定过两天还会出现很多意想不到的问题。不管他，反正今天特别的开心。

这周项目培训基本正常，效率还挺高。哈哈。由于项目组其他成员已经能负起责任，因此常规的事情基本不用管了。主要是每个部门培训快结束时，一定要到培训现场和双方沟通一下。了解存在的问题。根据问题的具体情况，协调部门和高层经理的沟通。如果属于我们自己的问题，一定要得出具体整改措施，落实人员和时间。以便后续跟进。

如果是开发商的问题，就形成纪要，小修改落实具体时间，如果发现需要进行大的修改，汇总一下，通知开发商，但是不要求立刻解决，等全面培训完成后。要求开发商和企业高层共同将重大问题进行方案讨论，并明确升级方案和具体时间。

这周对信息中心的人员职能分工进行了一些调整，将原来按应用系统纵向划分管理员的方式，调整成按服务器、网络、PC和应用系统推广实施两个小组。本来以为会遇到阻力，没想到非常顺利的完成了这次调整。这样一来工作职能就清晰多了。重新划分工作职能以后，即便于每个人明确学习方向，也好安排工作了。

最棘手的一件事就是计划部门强烈反应，系统中的数据虽然可以产生生产计划，但是无法自动得出三个月预测数据。为了得到合理的结果，召集跨部门的工作协调会，结果会上吵得不可开交。一开始我还以为是计划部门的操作人员不愿意承担更多的工作。在大家吵架的过程中隐隐感觉问题好像出在BOM的分类不合理。会上由于分歧严重，只好暂时宣布散会。

会后和各个方面进行了一些沟通，发现了由于各自站在不同的角度，很难达成共识。

实施顾问考虑到修改BOM会严重拖延实施进度，因此提出了几个局部修改的办法。但是我的直觉告诉我，问题的根源并没有得到解决。

技术中心由于修改BOM工作量太大，因此找出各种理由试图说服我，接受开发商的方案。在沟通中也承认BOM划分不太合理。

计划部门由于局部修改方案操作过于复杂，坚决抵制。并且理由比较也很充分。

虽然对每个部门反对的原因和理由都有了了解，但是对如何修改还是不能做出决定。

昨天在项目例会后，邀请两个部门的主管副总参加跨部门的协调会议，以便听取各方面的意见，共同决策。

经过一番激烈的争论，问题已经比较清晰了，最后两位副总都认可修改BOM，问题终于得到了一个合理的结果。

解决难题，如何有效的借助权威和专家的力量的确是种技巧。哈哈。

ERP终于上线成功了。哈哈！


从10月中旬回到重庆就一直忙，原计划10月26日上线，结果回来发现个方面的工作都没有深入下去，本来准备硬着头皮上线，然后出现问题再想办法解决。结果24日老板审查时，感觉BOM的编码规则不能适应公司未来发展的需要，全盘否定了。（说句公道话，这“家伙”是个顶级高手，被他否了一点都不丢脸。哈哈）



当时正在微软重庆办事处和他们谈判有关软件正版化的问题。突然接到信息中心的电话，告诉我：老板对BOM表的结构大发脾气，要求全部推翻重来！



听到这个消息，当时感觉脑袋发蒙，又不便当着微软的人说什么。只好支支吾吾的说知道了。看了一下表，已经四点多了，心想不管出了多大的问题，先把这里解决了再说。



尽快完成了谈判，出来后看了一下表，五点十分，马上开车赶回公司，路上给老板打了一个电话，告诉他我马上回来。有什么问题回来再谈，先不要着急。回到公司已经快六点了，赶紧上楼，一进老板办公室，感觉气氛非常紧张，主管技术中心的副总和技术中心主任、副主任，以及项目组主要成员都在。大家谁都不敢说话。老板在追问，每一个编码字段所代表的含义。问了好几个问题，回答都让他非常不满意。我在边上听了一会，觉得要是继续下去大家都得挨批。赶紧把话接了过来，这次出现这么大的问题，主要是我的责任，由于不懂产品特点，因此没有把好关。明天开始重新设计编码规则，尽量考虑的更周到一点。他到给我留足了面子，没说什么，就同意散会了。会议草草收场。



10月26号上线肯定泡汤了，不过首先感觉松了一口气。正好有时间将上线准备工作做得更加深入和扎实一些，会对上线后的工作有很大好处。可是想到：如果要从新制定编码规则，需要在PDM中对所有产品进行从新编码，这个压力就大了！要推动技术中心重新修改PDM中的数，然后倒入ERP，并且还要重新进行数据审核、基础数据准备等一系列工作。换句话说，前期所有工作全部报废！不由得倒抽一口凉气。搞不好今年这个项目就有可能搞不定了。要是十一月份不能上线，年底各个部门的工作都会非常忙，特别是财务部要进行年终结算，十二月就根本不可能了。只能拖到明年了。


这样一来整个公司的实施ERP的热情会受到严重打击，再重新启动项目的难度可能会更大，会极大的增加项目失败的风险。根据很多项目失败的经验表明，如果实施周期拖得过长，项目失败的风险就会增加。



看来只有拼了，尽量争取十一月底完成全部的基础数据准备。十二月上线。但是是否能实现这个目标，还要听听大家的意见。


第二天一早，召集项目组成员开会，讨论是否能够趁热打铁，争取一鼓作气十一月份上线。



会议一开始就遭到技术中心的强烈反对，认为根本不可能。理由是：



1、由于编码包含了很多新的内容：如车型代码，产品状态代码，设计变更版本代码等新增内容。PDM仅有四层树形结构，根本没法适应新的代码规则。



2、需要在PDM中重新设计产品结构目录，并且对全部产品重新编码，工作量太大，原来的BOM就搞了2个多月，根本不可能在十多天内重新推翻重来。（由于要给其他部门准备数据的时间，因此必须在十多天的时间内完成全部PDM的数据准备，并倒入ERP）。



从大家的脸上也可以看得出来，项目组其他成员也对我的提议报怀疑态度，只是碍着面子没有直说。



一时间会场的气氛有点尴尬。呵呵！可是我就是有点不信邪。倒不是我不知深浅，而是根据我们实施其他项目的经验表明，如果方法正确，工作深入下去，情况肯定能够得到很大的改观。并且前期对各部门的培训虽然没有深入，但是为提高效率奠定了基础。趁热打铁也许能成。不试试谁也不知道！



不过这个时候决对不能搞长官意识，强行命令只会适得其反。干脆让大家充分发表意见，谈谈到底还有哪些问题，我觉得：就是死也想死个明白。



结果大家提了一大堆的问题，最集中的是时间上安排不开，根据前几个月的经验，主要是由于各部门的配合不好，并且对系统根本不了解。所以计划根本无法保证按时完成。



看来问题明确了，会上我没敢强行推动。只是安排有关人员了解一些情况。



1、立刻与PDM开发商联系，落实是否只能支持四层目录树，有没有可能进行扩展。



2、整理会议纪要和新的编码规则，下发给各个部门，看看大家是否能理解新的编码体系，还有没有补充的内容。



3、归纳前几个月的实施准备工作，整理一个“基础数据准备”工作流程。



4、根据上述工作流程倒排数据准备时间表，找出关键节点和里程碑。



但是留了一句话，我还是想在十一月底上线，具体是否能做到，过两天再开会商量。

会后马上与技术中心的领导进行接触，深入了解到底为什么他们的反映如此的强烈。经了解后得知，主要是对老板的要求大家不太理解，感觉一些编码位不好进行分类。另外原来的编码方案也经过多次修改，大家感觉应该能够满足生产管理的需要。我由于不太懂产品，因此感觉我的能力无法说服对方，但是根据我的感觉，老板否定原来的编码方案肯定是有道理的。（这“家伙”是个专家，并且是个技术天才，有时候不服不行！）

最后我想出了一个折中的办法，就是技术中心同时提出两个方案，一个是坚持原有方案，但要加以详细说明，想办法证明原方案的合理性，另一个就是根据老板的要求，给出重新修改后的编码方案，提交老板审批。其实我的目的就是希望能更加深入的了解两个方案的差异是什么，并且能更加深入了解双方的想法。

两个方案经整理后，一起提交给老板过目，结果他还是坚持自己的想法。我把技术中心的有关人员一起召集到老板办公室，让他详细讲解他坚持的理由。经过一番不对称的讨论（应该说不上讨论，主要是批评。）不过大家好像终于有点理解新方案的合理性了。经过两轮的修改，大家基本理解了新方案的合理性。但是由于新方案的编码包含的信息量比较多，超出了PDM的支持的四层树形结构，如果重新编制BOM的工作量太大。

大家正在发愁的时候，好消息来了，PDM完全可以进行树形结构的扩展，不是问题！这下技术中心的工作终于做通了。我赶紧乘胜追击，经过一番“讨价还价”后，技术中心了承诺十八日之前将完成主要产品的BOM编制工作。

要是按原来的方法，技术中心将全部产品BOM编制完成后，提交给各部门审核，提出修改意见，然后技术中心进行修改，再导入ERP系统，由各部门开始准备基础数据。离二十六号上线仅有八天的准备时间，就是把大家累死恐怕也难以做到。

如何合理利用时间？这个好办，让技术中心将产品进行分类，编制完一个产品的BOM就提交审核，然后就导入ERP，各部门一边熟悉新的编码规则，一边同步进行数据准备，发现问题及时修改。经过仔细推敲，时间基本够用。

同时，为了提高会议和执行效率，对原来的实施小组成员进行了筛选，只留下各部门真正关键的人员，重新组建项目实施小组。

上述工作做完后，已经过去一个星期了。事不宜迟，立即召开新项目组开会，安排新的工作计划。这次会议开得比较成功。大家都明确了工作方法和自己的任务。