关注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系统的功能还没有充分了解是否配合用户管理需求之前就进行二次开发。因为用户的业务流程并不是一成不变的,ERP软件中流程一般比较抽象,大的方面与用户业务流程通常可以套上,细节部分不作修改也可以。同时,ERP软件不是给一个人用的,每个用户都可能有自己想法,不可能都满足的。部分要服从大局。项目按时、按预算完成实施,上线运行是实施阶段的大局,哪些二次开发必须要做,哪些可以不做,要看会不会影响大局。可做可不做的,坚决不做。
集成系统网络情报信息数据库
CIO频道人物视窗
CIO频道方案案例库
大数据建设方案案例库
电子政务建设方案案例库
互联集成系统构建方案案例库
商务智能建设方案案例库
系统集成类软件信息研发企业名录

