MES实施心得

MES实施心得
JDE实施心得
接触JDE今年是第3年了，说长也不长，但是从项目启动一开始就参与，一直到项目上线，再到现在的不断完善，从最开始的学徒，逐渐演变成现在的内部顾问。

角色发生了变化，同样心里也发生了不少的变化。

在项目实施的过程中，经历了很多，也积累了一些自己的方法与理论。

第一、实施前不要过大的夸口。

现在很多咨询公司，为了拿下项目，对客户夸下许多海口，既能解决这个又能解决哪个，把JDE说的很神奇，让准备上JDE的客户对JDE充满了信心。

这方面我觉得JDE 只是一个工具，工具使用的好坏完全取决于使用人。

好比武器，放在好人手里，只会起到自我保护的作用，一旦落到坏人手里，则会危害社会。

所以，一开始咨询公司把JDE说的那么神奇，不单单会给客户养成心里依赖，认为JDE是万能的，同时也会给实施公司的实施带来很多麻烦，容易造成双方矛盾，导致实施过程艰难，尤其是实施后期，一旦达不到客户的要求，就会互相推委，最后矛头指向系统本身，JDE 系统会很“冤枉”的。

第二、实施前，要考虑一下客户要上JDE系统的目的。

在中国，不少企业上JDE是冲着JDE的名声去的，抱着上市的需求或者其他造势的目的才选择了JDE，只有很少一部分是为了完善管理，规范流程才上JDE的。

实施方应该事先了解一下情况，对于目的不纯的企业，我感觉同样不要夸下海口，这类企业不会很重视系统，一把手同样也不会参与到实施过程中，通常会派一个小领导带着一帮小毛孩，跟着实施顾问边学边做，遇到问题却解决不了，这样会给实施过程带来很大麻烦，同样会严重影响实施效果。

第三、实施过程通常分为需求调研，调研文档，实施文档，开始实施，实施验收，后期支持。

我感觉最关键的是需求调研，同样也是最难的。

没有参与实施的人可能会觉的JDE 系统一点也没有接触过，这应该是最难的，其实不然，做不好需求调研，了解不全客户的需求
以及现有情况，不能在一开始将不规范不正确，存在的隐患避除的话，后期接踵而至的会是无穷无尽的推倒、修改，再推倒、再修改。

这点我深有体会，需求调研匆忙的做完后，开始了第一次实施，结果效果达不到要求，只是让跟着项目的小毛孩们了解一些简单的系统配置。

最后顾问们做的实施文档完全否定，重新做了新的文档，才满足了部分的需求，项目才得以继续进行。

第四、ERP系统是双方面的事，这点要牢记。

很多企业上ERP存在一个观念“我给你实施公司钱了，剩下的你就要全给我办好了”。

要知道每个企业有每个企业的特色，顾问是不可能会了解企业所有的特色，最了解企业的是企业内部的员工，尤其是关键员工，所以实施过程中少不了双方的配合。

员工详细描述企业的流程及特色，顾问针对描述提出合理的解决方案和实施方案，然后进行讲解，双方经过反复的协商，达成一致的意见，再开始实施。

这样同样会避免以后的反复修改，最大限度的保证项目的顺利进行。

同样，在系统上线运行的一段时间内，会碰到终端用户的种种要求，恨不得点一个按钮，系统就能把所有工作都完成都实现，并且还能按照不同人的不同喜好显示出来，针对这点，我认为ERP项目不是扯
皮的项目，必须要有一定的力度，对于一些不合理的要求一定要给予坚持的否定，项目经理一定要把好管控，一旦开了头，之后会有无穷无尽的麻烦和要求。

第五、经常说ERP是“一把手工程”，但是很多企业没上ERP时并不以为然，直到花了钱买了教训才知道。

这里的原因个人认为主要是对ERP项目的理解不到位，认为ERP项目紧紧是实施一个软件，不能说这种态度是错误的，但是如果这么做，那么就要降低自己的期望值，并做好后续一系列问题的心理准备。

如果想做好ERP项目，那么就一定要“一把手”参加，将项目上升到正确的高度，公司领导能够全力支持项目，扫除项目中会遇到的一切障碍，因为ERP项目也是一个变革项目，变革缺少了领导支持，则注定了失败。

所以上ERP项目，一定要从思想上认识到位，然后从行动上做到位，尤其是公司领导。

第六、说说企业内部的项目组成员应该怎么做吧。

个人认为，在
项目实施初期，项目组成员会是一头雾水，根本不知道自己再干什么。

这就要求项目组成员一定要有耐心，毅力，对于顾问们要求的工作不懂的可以先放下，记录下，等系统上线后，再回过头看这些问题，你会觉得豁然开朗，一切问题都已经不是问题。

如果说一个项目组成员成长最重要的时期,我认为不是项目一开始,而是项目后期,尤其是上线的时期以及最初的维护时期.我曾经差点犯下错误,学会了配置菜单、配置系统，就认为很了不起了，就想跳出去，现在想想，很庆幸当时没有做出错误的决定，在上线和维护的初期，问题是最多的，只有通过不断的发现新问题，解决新问题，成长才是最快的。

第七、ERP项目不单单是IT部门的事情。

在许多公司中发现，领导普遍认为ERP项目就是IT部门的事情，所有的事情应该都由IT部门解决，包括流程梳理，物料编码，需求解决。

涉及到的部门，只需要将自己部门的需求反应给IT部门即可，至于需要和那些部门协调，怎么做的事情则统统是IT部门的事情。

这种观点不完全正确。

据我了解，绝大部分公司的IT部门人员技术力量很强，但业务力量很弱，因为不能实际的到业务部门实践学习，这种情况导致IT部门通常是为技术服务，而非决策。

如果一个公司在ERP项目初期将IT 放在一个决策的地位，则注定IT部门真的“挨踢”，ERP项目也会做的不伦不类。

除非这个企业的IT力量很强，对业务非常了解并且具有相当丰富的管理思想，我想这样的人员早应该是企业的某个部门的管理者，而非IT人员了。

举个简单的例子：编码问题。

编码流程大体分为申请——审核——录入系统，这个流程中如果将审核和录入系统两个阶段全都放到IT 部门，而IT部门负责编码的人员不具备审核的能力，则编码一定会乱。

这个时候恰当的做法应该是找几个经验丰富的人员组成专门的编码小组负责审核编码，包括命名，型号，库存等信息，之后可以由IT人员录入系统。

所以在ERP项目中，公司应该对IT部门的定位比较准确，在IT业务力量比较薄弱时，要放低IT部门的地位，但可以在过程中不断的培养IT人员的实力，有一天IT部门才会达到公司期望的位置。

第八、理论讲了不少，实施方法中有一点比较重要，就是书面文档。

在很多企业的实施过程中，并不注重书面文档，很多沟通只是开
会讨论，排板决定，然后就完了，会议纪要没有，会议总结也没有；再或者与他人沟通时，只是口头请教一个问题，之后就完了；做一个测试，只是做了，过程与结果没有形成书面文档，这些在过程中都是比较容易忽略的。

之所以强调书面文档的重要性，是因为ERP项目是一个长期的项目，项目在进行中会不断的变
化，不断的更新，那么如何有效的记录整个项目的过程，如何回头判断项目之前的效果，如何查找项目过程中确定的流程、制度等信息，只能通过形成书面文档。

我的经验是好记性不如烂笔头，培训到现在，我已经记了2个笔记本，并不定时的在博客或其他地方记录自己的收获，对于项目中的大小会议以及流程的变更，都会及时的形成书面文档并发给相关人员。

随着时间的推移，我慢慢的发现了这些好处，如果在项目后期出现了一个似曾熟悉的问题，我可以及时的翻阅前期资料进行确认。

如果后续别人对你的流程提出异议，我可以拿出之前的流程确认文档进行讨论。

如果后续对系统功能有不了解的地方，我可以拿出笔记进行参考。

逐渐的，这些文档甚至可以形成一套制度，一套流程的规范制度，更加有效的管理。

暂时先想了这么8点，以后再有想法会及时补充。

经过这么久的努力，已经实施了7个公司的ERP项目，除了两个大的公司是借助了顾问的支持，剩余的小公司都是独立的完成的。

呵呵，比较有成就感。