[案例] 过度二次开发 ERP实施易陷困境

蓝色虫

作者: 潘少红



酷热的8月，华南重镇深圳。空气中充满阵阵扑面而来的迫人热浪，但我却感到阵阵的寒意。我是一个ERP实施顾问，现在我正协助客户ERP项目上线，这是客户有史以来在管理上最大的IT项目。但经过大半年的实施，项目却陷于绝境。在痛苦之中，作为项目实施的我都有些感到心灰意冷想要放弃。原因是客户对ERP软件二次开发的误解和随意性的二次开发，使项目陷于前无进路，后无退路将要给暂停的局面。

　　ERP软件实施最让人感到恐怖的就是过度二次开发。在多数情况下，ERP二次开发都会演变成一个对系统无休止的修改过程，最终会把客户和厂商都拖进泥潭难以自拔，而开发人员和实施顾问则会心力交碎，生不如死。

　　一.客户固执己见，财大气粗自行二次开发

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

　　我现在负责的项目中，客户固执的认为只有进行二次开发才真正发挥它们自身个性化的流程潜力。客户有一个非常大的误区，就是想把现在的手工流程、手工作业一成不变的搬到ERP中去，其实这是非常不正确的，这只是换汤不换药的做法。当我与客户领导进行沟通时，分析ERP现有的流程与客户原有的流程的优劣性比较时，客户以一句话把我顶住，就是他们一直是这样做，而且还做得不错，他们就是用这样的管理手段得到发展，而且以后还打算一直用他们习惯的方式去管理。

　　客户除了在业务流程方面有个性化需求外，还存在着一些不涉及业务流程的需求。例如单据/表格的格式，一般ERP都会提供通用的单据格式，而用户又有自己习惯的一套单据格式。在ERP实施时，企业第一个问题就是问能否按这个格式打印。其实，这是本末倒置，只要该有的内容有了，没有必要一成不变的按原有的格式。也许ERP系统提供的格式更加合理，就算是二次开发，也许等格式修改好了，客户也许早就适应了这个新的格式，这样的问题在实施中时常出现。因此，在与客户沟通这些无关痛痒的问题上常常让我费尽心力，舌根冒火才勉强说服客户同意先试用单据格式。结果是不但容易造成项目延期，而且还把大家注意力转移到无关系统的核心流程上，吃力不讨好现象时常发生。

　　当然，有时客户确实存在着一些个性的业务流程需求，ERP系统无法满足，毕竟ERP是一个套装软件，而不是根据客户量身定制的。针对这种需求，即使通过各种各样的实施方法后，也没有找到更好的处理方式，那只好进行二次开发了。针对客户频繁的二次开发需求，我们把利弊向客户陈述清楚，并说明无数的事实证明大量由于不合理的管理流程需求提出要二次开发的案例最终会都失败。而且许多开发需求已经超出软件厂商应该负责的部份，需要额外签订二次开发合同和增加费用。最后，财大气粗的客户领导决定扩充原有的IT部门开发组，自行进行二次开发。

　　二.无节制二次开发，项目陷进退两难困境

　　ERP软件在实施的过程中总会遇到这样那样的问题，许多实施顾问都非常头痛的是二次开发。更不幸的是，因为客户领导一时意气用事，再加上财大气粗终于造成过度二次开发，不但成本过高，而且越改越让项目难以实施，陷入进退两难的困境。

　　(1)大量无节制开发，系统完全变味

　　客户老总在ERP实施前就为实施定了调：现有的业务流程不能大改，只能逐步优化。为此，针对客户的业务流程个性化需求，我估计开发量会不少。因此，作为实施顾问的我在与业务部门讨论解决方案前采取了如下应对策略：先培训客户尽快熟悉ERP系统功能，劝说客户采用系统已有的相似功能，减少一些无谓的开发，系统没有的功能才考虑是否要开发。

　　在与业务部门就方案讨论时，我的态度一直是极力反对对系统做大量开发，认为该软件是在数万家企业使用的，管理思想是非常先进和合理的，而且大量开发不但会有开发的风险，延长了实施周期，还会对系统升级带来诸多不便。但客户坚持开发的理由是：①现有的流程支持公司快速发展，目前使用的流程是经过实践检验了的，只是需要更进一步完善;②ERP流程或许先进，但不可能因为实施ERP而大改，太大的调整将导致上下衔接不顺，就连正常的运转都难以维系，上ERP就是找死。

　　就这样，实施小组和业务部门讨论、协商、争论了个把月，结果是一大堆的二次开发需求摆在面前。让处在中间的我犯难了：开发吧，时间长、风险大;不开发吧，业务部门需求在客户老总看来是理所当然的。还有令我更为难的是，如果拒绝，实施方案没有业务部门的签字，客户将拒付实施费。在二次开发和项目停顿的两难中，我无奈的选择了前者，在同意二次开发后业务部门才陆续在实施方案上签字确认。

　　然而，大量对某些不规范的个性化业务流程进行二次开发后结果是：项目延期;开发的程序不稳定，容易出错。用了一段时间后，发现还不能满足业务流程的需要，于是客户再做修改。实际上，这样二次开发就可能存在两大问题，第一是由于二次开发过多，系统变得越来越复杂，与最初期望的效果越来越远，最后猛然一看，系统已经完全“变味”了。第二，由于客户二次开发能力有限或者系统柔性度较差，造成客户在这方面的投入很大但产生的效益甚微，后者也正是客户在二次开发中陷入窘境的主要原因。

　　(2)开发人员流失，项目陷入困境

　　在初步估算开发量后，客户深知开发任务的艰巨，于是要求软件厂商提供高级技术顾问调入二次开发项目组作技术指导和支持。在制定二次开发计划后，软件厂商开发技术顾问也投入了紧张的设计、开发过程中，并开始指导客户开发人员先进行一些简单的开发。

　　然而，客户公司的开发人员以前都未接触ERP软件的开发，同时还需要维护公司其他系统，人员也三心二意。因此，起步格外吃力。而且事情发展下去越来越糟，由于客户开发人员在项目中多次被投诉进度慢，客户公司在例行的加薪中没有给开发人员加薪，这些令他们怒不可遏，本来开发就挺累的，累了还不值，公司没有重视他们的价值。在后来的开发中，他们没有象开始那么积极和负责了，整个项目的开发开始陷入不正常之中。

　　项目就在开发人员的三心二意中继续，本来确定的上线日期也因为二次开发的未完成和项目方案的反复调整而一拖在拖。眼看再不上线，整个项目将严重滞后，客户不得不强行上线，留下一堆尚未开发完善的程序等待测试。项目上线后，业务部门在使用中，相关的开发程序逐渐暴露出了问题，不是今天这个报表运行出错，就是明天那个功能计算有误，整个项目实施组陷入救火当中，尽管开发人员对前期的开发程序进行了修修补补，但问题还是层出不穷，不时接到业务部门的抱怨和不满，整个企业迷漫了对ERP失败的看法，原来美好的愿望在现实中被击的粉碎。

　　面对如此尴尬局面，不得已客户将所有的二次开发力量集中于ERP项目，并要求开发人员加班加点，指望能够扭转颓势。但是，一些开发人员变得更为不满，本来待遇就低，现在又加班又没什么激励措施，干多干少一个样，有的人开始消极怠工，一张报表做个十天八天，稍有难度的开发就拖泥带水的。随着时间的推移，他们感觉工作没什么意义，有的人开始考虑跳槽，提出了辞职。在这个节骨眼上提出辞职，项目进度只有拖延，整个项目二次开发最后陷入停顿。

　　三.反思过度二次开发的得失

　　当客户明确提出要二次开发的时候，如果控制不善非常容易出现项目延期，开发的程序不稳定，或者需求反复更改。但可能涉及当初拍板决定的各方领导的利益问题，所以过度二次开发的程序即使成了鸡肋，扔也不是，不扔也不是。

　　(1)应先引导客户对二次开发正确认识

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

　　(2)严格遵守不随意修改核心代码，新功能应独立成模块

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

　　(3)严格审核需求，不随意开发

　　二次开发的需求必须控制好，尽量不要在ERP系统的功能还没有充分了解是否配合客户管理需求之前就进行二次开发。因为用户的业务流程并不是一成不变的，ERP软件中流程一般比较抽象，大的方面与用户业务流程通常可以套上，细节部分不作修改也可以。

　　严格审核哪些二次开发必须要做，哪些可以不做。要明确这些原则：可做可不做的，坚决不做;某些无关痛痒的流程，如某些单据的审核流程可以缓改，或用手工的方式去控制;对于界面的调整，也应该缓改或者不改。因为由于使用的不便等原因而对系统改这改那，很容易犯了拆东墙补西墙的错误，导致软件开发了客户却不能用不愿用的尴尬局面。

　　(4)二次开发团队稳定是重中之重

　　作为一个开发项目来说，保持相对稳定的开发队伍是非常关键的。如果人员频繁的流动，没有相应的奖惩措施，那么无法调动积极性，也就无法进行持续的开发，项目陷入困境也就是必然的事情了。