A公司实施Oracle ERP系统已经有好几年的时间，而且也通过实施ERP系统获得管理水平的提升，同时为了提高不同部门员工使用系统的效率，结合企业的实际情况，在ERP的标准功能基础上，开发了很多可以提升业务部门工作效率的功能点。但经历了几年的不断开发以及完善，现在企业遇到了新的难题：1、开发出来的各种各样的子系统无法整合，维护工作困难;2、单点功能的开发提升了最终使用人员的效率，但对整个业务流程未见提升，甚至影响流程的稳定性;3、开发的功能不断增加，系统复杂度以及耦合度增大，系统稳定性难以保证。A公司的烦恼很有代表性，也代表着我们对ERP二次开发的观点，难道真的尽量减少二次开发，使用系统的标准功能吗?笔者觉得，ERP实施过程中，多少的二次开发量才算合理，不同的企业不尽相同，但必须把握好二次开发的原则：这个原则与当初企业为什么要实施ERP系统是一样的，希望通过实施ERP系统提升企业的管理水平，优化企业的流程，而不是仅仅提高某部门或某员工的某功能的工作效率;提高员工的工作效率固然重要，但任何东西都有取舍，不是任何可以提升员工的工作效率的开发都要去做，当此工作效率的提升反而会影响业务流程的稳定性，坚决不做;如果此开发的工作效率提升，并未对业务流程以及管理水平有帮忙，尽量少做。明确ERP二次开发的目的以及原则后，需要对二次开发进行规划。

　　1、 对整个企业的业务进行IT规划

　　结合选择的ERP系统，明确哪些系统可以通过标准功能可以满足的，哪些业务流程系统标准功能无法符合企业的需要进行开发;这必须是从业务流程的角度去考虑，而不是某个功能点去考虑;不能因为某个业务部门想法而随意改变计划，就像大的方面，企业的信息化分ERP、CRM、SCM、PDM等，根据企业的实际，希望先重点解决哪些业务，就ERP而已，哪些业务流程是ERP系统标准功能很好支持的，哪些业务流程必须通过开发来改善系统对此流程的支持的。

　　2、 开发要有所取舍

　　对所需要的开发进行规划后，确认开发的先后顺序，并明确不同子系统开发的侧重点后，对具体的流程开发时，要有所取舍。对于某个业务部门来说，他们的需求都是基于其工作现场而提出，但正像文章前面所说，无论是二次开发还是ERP实施，都是为了提升企业的管理水平，对业务流程进行优化，但很多最终用户提出的需求，只是基于其功能点，而不会考虑对整个业务流程的影响，更谈不上对管理的提升。例如，很多批量下达采购订单，批量关闭采购订单这样的功能，单从系统来说，的确可以提升采购员的工作效率，但从业务流程的角度来考虑，系统关闭任务时是为了检查作业的相关信息是否无效，如果批量关闭，用户根本就不会去逐个检查，这样功能实施批量关闭了，但这个业务的控制点却减弱了，反而不利于整个业务流程的控制。这样看似提升最终用户的开发而对业务流程无利的，要慎重，必须站在业务流程的高度去考虑，有所取舍，要问，到底此开发，对提升企业管理是否有帮助。

　　3、 开发的效率与可维护性

　　当最终确认需要通过二次开发来解决后，进行实际性开发阶段，这时候进行开发必须把握原则，到底是开发的效率重要还是后期可维护性重要，特别是对于哪些企业内部IT人员自己进行的开发，对于业务人员来，每个功能的开发总是要求很紧的，一个月的开发工作量非要说10天要做出来，这样的后果是，任何开发需求文档不再编写，直接进行编码阶段，直接让开发人员把功能开发出来让用户使用。先不说开发的质量如何，最要命的是，后期程序发生变化需要修改时无法维护。笔者近期做了一个客户的二期项目，一期的项目做了大量的二次开发，但经历一年时间后，IT人员流失得差不多，到现在没有一个人能清楚到底做了哪些开发，这些开发到底实现了什么功能，如何设置使用根本就无人能说得清楚，大部分的开发涉及到各种模块，更不用说后期的修改了。对其修改直接影响到原来功能的使用，而有不少人员认为，当比较紧急的情况下，可以先开发，后补文档;但笔者经历了这么多的项目与客户，后补的文档质量根本就不能让人相信，都只是应付形式的。因此，对于企业ERP这重大管理系统，开发的效率当然需要追求，但如果以牺牲流程的稳定性以及日后的可维护性的话，这样的开发效率是否值得提倡。

　　企业的ERP系统必定是管理系统，管理系统并不能仅仅通过IT的力量就可以成功的，ERP的二次开发也是为了服务于此管理系统而为企业的管理目标而服务，如果离开这个目标是一味受制于业务部门的需求，只会使ERP这个管理系统越来越难以管理，最终造成管理的混乱而不是提升。因此做ERP开发前，必须进行规划，确认此开发是否对企业管理有所提升，是否有利于业务流程的顺畅。同时开发是服务于流程提升，因此开发并不是越快越好，必须在开发的质量与可维护性有所保障的基础上追求开发效率。