导读：多数情况下，二次开发都会演变成一个对ERP系统无休止的修改过程，最终会把用户和厂商都拖进泥潭难以自拔，而开发和实施顾问则会心力交碎，生不如死。 

 

 

 

　　无休止的ERP实施加班后，我终于迎来了难得的半天休息，在家舒服地看了电影《特洛伊》让我感受至深——古希腊神话中所向披靡的勇士阿喀琉斯最怕脚后跟受伤，成为其致命的“命门”，其实ERP也有最怕触及的“命门”，这就是二次开发。

　　多数情况下，二次开发都会演变成一个对ERP系统无休止的修改过程，最终会把用户和厂商都拖进泥潭难以自拔，而开发和实施顾问则会心力交碎，生不如死。

固执己见的客户 

 

 

 

 

 

 

　　在我做ERP实施顾问的第一天，上司告诉我第一条准则就是要以用户需求为驱动。然后，上司又告诉我第二条准则：作为实施顾问要坚决不赞同用户进行太多的二次开发，过多的二次开发不仅会增加软件的不稳定性，还会延长实施项目的周期，从而增加项目成本，要用尽各种各样的办法把用户需求向ERP软件已有的流程上走。这两个看起来相互矛盾的准则，令我在近期一个ERP项目实施过程中感到生不如死，左右为难。

　　用户是一个老国企，在界面上和操作上提出非常多的特殊要求，固执地要求按他们的习惯进行二次开发，以满足他们原有的操作模式。一般来说，我们的ERP软件产品为了具有较强通用性，软件功能已经比较标准，流程设置也相对规范化。虽然通过参数可调的形式可以部分满足不同用户的需求，但很多情况下这种“轻度”灵活会失效。

　　用户的固执或偏见主要是表现在这几面：

　　①不愿意改变现有的操作习惯。用户想把现在的手工流程、手工作业一成不变地搬到ERP中去，而这恰恰是换汤不换药的做法。当我对用户分析ERP现有的流程与用户原有的流程的优劣性比较时，用户一句话就把我顶住，说我们一直是这样做，而且还做得不错，我们就是用这样的管理手段得到发展，并且获得了上你们ERP系统的资金，以后还打算一直用我们习惯的方式去管理。

　　用户除了在业务流程等方面具有个性化需求外，往往还存在着一些不涉及业务流程的、由企业的特殊性而产生的个性化需求，例如单据/表格的格式。一般ERP都会提供通用的单据格式，而用户又有自己习惯的一套单据格式。因此在实施时，企业上来就问能否按这个格式打印。其实，这是本末倒置，只要该有的内容有了，没有必要一成不变的按原由的格式。

　　这样的问题在我参与的实施中时常出现，与用户沟通常常让我费尽心力，舌根冒火才勉强说服用户同意先试用单据格式。这样不但容易造成项目延期，而且还把大家注意力转移到无关系统的边缘流程上，吃力不讨好现象时常发生。

　　只有当碰到无法通过调节参数来完成；或者报表功能真是不适应用户需求时导致报表样式、内容要改变，这些情况才应该通过二次开发来实现。这种因操作习惯提出的二次开发主要针对用户各类报表系统的查询，打印格式和字段标准化等方面。

　　②不合理的管理制度造成的特殊流程需求。用户有些二次开发需求，是原先不合理的管理制度和流程所造成的。因此，我们首先要做的是判断其要求的合理性，然后深入到一线去找出真正的需求。而无数的事实证明，大量由于不合理的管理流程需求提出要二次开发的案例最终都失败了。

　　③ERP软件确实无法满足需求。当然，每个用户确实都存在着一些ERP无法满足的个性业务流程需求，毕竟ERP是一个套装软件，而不是根据用户量身定制的。针对这种需求，即使通过各种各样的实施方法后，也没有找到更好的处理方式，那只好进行二次开发了。

二次开发的风险 

 

 

 

 

 

 

　　当用户明确提出要二次开发的时候，则很容易出现项目延期、开发的程序不稳定容易报错等问题；或者用了一段时间后想再做修改，才发现原来当初这样做是不对的，但可能涉及当初拍板决定的各方领导利益问题，所以也没人敢改了，因此导致二次开发的程序成了鸡肋，扔也不是，不扔也不是。

　　①修改报表格式或用户查询系统等不涉及程序代码改动的需求相对简单，因为软件一般都具有报表生成功能，任何业务人员不需要有很多计算机知识就可以自行设置，这种情况在实施时经过实施顾问组与用户充分沟通一般比较容易解决。

　　②当用户需求具有个性化，并涉及改动程序代码时，工作就很复杂了，往往需要ERP系统提供支持二次开发的工具,还可能需要有厂商软件的源程序支持,这些大都要支付额外费用。

　　当用户提出需要代码级二次开发时，实施顾问必须清楚与用户沟通，否则更易陷入泥潭，因为代码级二次开发可能会使ERP系统变得越来越复杂，变成一个“四不象”的浮肿庞杂的ERP系统。

　　一般来说，代码级二次开发主要有以下三个方面的风险：

　　①易造成系统的不稳定或崩溃。ERP系统是个错综复杂的系统，各个模块是个有机的整体。若要修改其中的一个功能，其影响的不单单是现在这个功能，还可能影响到其他功能。目前实施顾问一般对ERP代码级二次开发的一个观点是：能不做就不要做。因为ERP系统就像人的血脉那样错综复杂，在二次开发的时候，如果因为增加的用户个性化功能触动了ERP原有的大动脉，否则会大大影响其整个性能，并且开发、调试的费用也是非常吓人的。

　　②严重影响项目实施周期。代码级二次开发的时间短则几天，长则半月、一月，甚至也可能长达几个月，很容易延误项目实施进程,这个因素应该在签定合同或者说制定项目实施计划时包括进去。

　　③后续维护和升级风险大。改动软件后还会影响以后的软件版本升级。如果不升级,新版本的长处无法应用。如果升级,则面临着重新进行二次开发的可能。因为ERP软件供应商在进行新版本的ERP系统开发时,可能根本不会考虑某个特定的用户在旧版本上所作的二次开发。因此,在进行二次开发前,要做认真的分析对比。究竟是修改软件,还是改革现行管理程序，还是两者都作一些修改，对修改的必要性、效果和代价要心中有数。

反思ERP二次开发的得失 

 

 

 

 

 

 

　　无论是实施顾问还是用户都可能产生过这样的感慨：明明是经过几个月的初期讨论和项目分析，在用户的认可下做好了的ERP系统，结果由于“二次开发”，系统变得越来越复杂，与最初期望的效果越来越远，最后猛然一看系统已经完全“变味”了。因此，把握二次开发的原则很重要。

　　①在观念认识上，实施顾问应要让用户清醒认识到，不应过多强调用户自身的特点，ERP软件中的管理流程是从许多企业中提炼出来的，具有先进性和合理性。许多用户的特殊之处都是由于流程自身的不合理产生的，应该通过ERP的实施，对企业进行业务流程优化或重组，而不是一味修改软件以适应不合理的流程。

　　②当需要二次开发时，实施顾问和开发顾问应该要严格遵守不修改核心代码这一条基本原则。如果必须进行二次开发，则应尽量使得二次开发做出的功能模块独立于原来的ERP系统。这样当ERP系统版本更新时，二次开发出来的模块无需修改或者只需较少的修改就可以应用于高版本的ERP系统。

　　③二次开发的需求必须控制好，尽量不要在ERP系统的功能还没有充分了解是否配合用户管理需求之前就进行二次开发。因为用户的业务流程并不是一成不变的，ERP软件中流程一般比较抽象，大的方面与用户业务流程通常可以套上，细节部分不作修改也可以。同时，ERP软件不是给一个人用的，每个用户都可能有自己想法，不可能都满足的。部分要服从大局。项目按时、按预算完成实施，上线运行是实施阶段的大局，哪些二次开发必须要做，哪些可以不做，要看会不会影响大局。可做可不做的，坚决不做。

附录：

ERP二次开发处处是坑，该如何避免？

不管是甲方还是乙方，首先为什么有这样的问题？那肯定就是ERP项目上大家曾经遇到过一些或者不少的坑。

要想避免ERP项目在二次开发上的坑，那么我们得搞清楚以下几个问题。

一、为什么会产生坑（甲乙双方都有原因）？ 

1、项目实施过程不是由同一实施人员（或者团队）负责。

因为有些软件公司在追求利益的过程中，（也是为了让公司可以经营下去）以快速上线收款为目的催生下就逐渐产生了一种模式，项目初期会将自己最好的实施资源用在项目上，以拿到80%的项目款，后期的时候就可以将项目交给实施能力略差一点的实施实习生等去维护，基本就是一些超细枝末节的问题，但是呢这些细枝末节的问题他们在处理起来都会用“障眼法”就是仅考虑眼前的问题，不考虑这个问题可能会产生的其他影响，并且实施员有一种心里就是，我现在处理了，那么到下一个实施员那如果再遇到问题就不关我的事情了。

这样就导致了软件使用者在使用上不美好的体验。最表面的感觉就是被这个ERP给坑了，隔三差五有问题。

2、实施团队内部的人员水平参差不齐。 

现在市面上很多软件公司的实施人员都是快速培训上岗，对软件以及客户方的业务流程跟本没有全局的了解（这点也是ERP行业实施顾问男培养的原因）。一般情况下用户会明确的提出需求，比如：修改报表格式或用户查询系统等，这类不涉及程序代码改动的需求相对简单，因为软件一般都具有报表生成功能，任何实施人员不需要有很多计算机知识就可以自行设置，这种情况在实施时经过实施顾问组与用户充分沟通一般比较容易解决。但是很多时候因为实施人员没有全局概念，在之前修改完后一段时间又像修改才发现原来当初这样做是不科学不理智不对的，但软件修改过程呢每一步都是得到甲方领导认可与审批的，出于怕惹麻烦或者领导的面子，所以也没人敢再去找领导明目张胆的指出当初他的决定是一件多少傻的事情，因此导致二次开发的程序成了鸡肋，扔也不是，不扔也不是。

多方面原因导致这个坑，用户不得不跟着赴汤蹈火的跳啊。

3、甲方爸爸说一不二，一定要软件去适应他们的流程。 

如果遇到这样的项目，其实实施人员离生不如死已经不远了，为什么这么说呢？

用户方很多都是在自己发展上升趋势的时候会选择上信息化项目，但是在软件厂商而言ERP的流程都是千锤百炼的，erp厂商的原则就是尽可能的将客户流程往标准流程上去靠拢，但是一旦遇到特立独行的甲方爸爸，他们坚持将自己最初的原生态操作流程一点不动的搬到ERP系统中，这种一般都是涉及改动程序代码的，工作会变的很复杂，往往需要ERP系统提供支持二次开发的工具，还可能需要有厂商软件的源程序支持，这些大都要支付额外费用。不是说不能做，只要有配套的二次开发工具其实不管什么需求都是可以实现的，只是这个个性化做出来是不是可用，对系统后期使用影响是什么样子的，因为代码级二次开发可能会使ERP系统变得越来越复杂，变成一个“四不象”的浮肿庞杂的ERP系统。

4、ERP软件厂商没有专业的二次开发团队。 

很多ERP软件厂商（或者代理商）基本上实施团队是和二次开发团队没有划分的，实施团队的人员也充当着二次开发的功能，但是实施团队在实际工作中还是偏对甲方业务流程的分析优化以及甲方用户软件使用技能提升培训方面，而二次开发人员则是需要将甲方的需求通过琢磨研究后台调整并且测试以及将后期影响尽可能的全局考虑一下，在最终给出解决方案的团队，而不是说一味的同意甲方或者拒绝甲方。

那如果没有专业的二开团队基本就是要么全盘接受要么全盘拒绝，为了实现需求而实现，最终自己挖了个坑把自己给埋了。

二、那么如何避免ERP项目中二次开发的无底坑？ 

1、作为甲方，在项目开始之前就要明确好你是不是打死也不接受通用版？一定是需要做二次开发的？

那么就在选择ERP软件供应商时候，就要注意几点：

1）供应商是否有自己的专业成熟的ERP软件产品；

2）是否有自己配套的二次开发套件；

3）是否有专门的二次开发团队；

4）目前市场上服务口碑如何；

5）最主要的就是目前情况下，是否有自主研发的能力了。

2、作为乙方，要合理疏导以及正确判断甲方的需求。

1）首先要沟通好后期会不会产生大的二次开发啊（涉及到代码修改的层次，怎么收费是要在合同中注明的，当然如果一开始是无法定价那么也要有相关的说明）。

2）一开始要给甲方意识就是ERP软件的流程是经过多年多次多家客户的使用修改提升总结出来的，甲方企业的流程尽可能的是去往标准流程上去规范去靠拢，ERP是带这么一种管理思想，管理习惯，如果甲方一开始坚持是不能接受通用版的流程那么就是得走定制研发的路子，那么上午谈判上就是另外的定价了。

三、早日脱坑 

这个需要我们甲乙双方在ERP项目意识上有比较高的思想觉悟，甲方不要顽固的坚持自我，要开放性的接受或者去思考乙方提供的一些流程改善建议，乙方也应该充分的考虑甲方所属行业的一些客观个性化因素，双方保持积极良好的沟通机制，软件乙方不赚快钱，不坑客户，坚持将服务意识贯穿到整个项目中；甲方客户以一颗发展，开放的心在信息化的过程中持续成长。