企业资源管理系统（Enterprise Resource Planning，ERP）即是对企业资源进行有效共享、计划与利用的管理系统。尽管几乎每一个ERP系统都试图集中良好的信息技术和先进的管理思想于一身，但是，不可否认，每位用户都有他独特的管理理念，这样的理念不可能和他所选择的ERP系统完全的融合。这也就使得ERP系统进行二次开发成为必然。而经过二次开发，对原来的ERP系统难免带来风险，如何认识风险，在认识的基础上，又该如何对风险进行控制？从而提高ERP系统二次开发生产力。在多年实践的基础上，我们在这方面做了一些探讨和研究。
一、从组建两个项目组的管理思路开始
通常，当企业和用户通过项目前期咨询阶段，达成基本的合作意向之后，整个项目就进入了启动阶段。ERP项目并不纯是一个技术项目，更是一个用户企业内部的管理项目。当整个项目进入了启动阶段，实际上也就意味着两个项目的启动，一个项目是企业的管理理念的调整，另一个是启动的项目是系统供应商对用户的需求调研到最后项目的实施等工作。“两个项目”的关系如图1所示。
图1 “两个项目”的关系
所谓用户所在企业的管理理念的调整，是指用户所在企业需要专门组成一个项目组，项目组中最好包括企业的高层领导。在项目开始启动时，最需要考虑的事情是：企业的发展中积累了大量适合于本企业的管理经验，而所选的ERP中包含了被业界普遍认可的一些通用的甚至是经典的管理理念，在这二者中如何取舍呢？也就是说要在企业的业务流程重组和ERP系统的调整（包括客户化和二次开发）中间做一个合理的选择。这是一个重要的选择，而这个选择也意味着企业需要承担由此带来的风险。为了配合所开发系统的合理使用，企业还需要进行组织机构和工作程序的相关调整，以便更好地吸收先进的管理理念，同时又保有自身的特色。然而在大量的实际调研中，我们发现如此重要的一个项目理念，在实施ERP的过程中竟然常常被企业忽略，甚至没有对所选用ERP带来的理念认真地学习，就匆忙决定实施，或决定进行二次开发，这样的后果可想而知。
而另一个启动的项目就是通常我们看到的系统供应商提供的服务。这个项目往往看似重视，而实际上是一种比较轻率的实施，甚至是一种在用户的主导下被动地工作。其实，我认为两个项目的展开，应该有一个严格的时问安排和交叉点，两个项目互相配合才能降低项目的风险，这并不是一个简单地将企业的管理信息化。
二、选择客户化和二次开发的合理
由于各行各业的千差万别，任何一个ERP系统都不可能“放之四海而皆准”，ERP系统避免不了因各个企业的不同业务特点而出现无法满足企业要求的状况。所以，在经过对企业的管理理念和ERP的系统带来的管理理念有效的取舍后，ERP系统几乎无一例外地需要进行客户化和二次开发。而合理进行这样的选择，也能有效地避免ERP系统的风险。
一般情况下，我们认为，不牵动程序的改动为客户化；而改动程序的工作称为二次开发。客户化和二次开发是两个容易搞混的概念，客户在项目的实施中，对此往往不能很好地区分。从工作量和难易程度看，客户化远远小于二次开发。好的系统尽量提供系统参数，通过参数配置（Configuration）来满足客户业务需求，而不是动辄就通过写代码完成。这样做的好处是实施速度快，对系统没有任何伤害。一套ERP系统的优劣从参数数量上就可以区分。灵活的参数设计可以让客户通过参数的自由组合来满足复杂的业务。随着IT技术的发展，现在各ERP厂商都在系统功能自定义、报表自定义等方面大做文章，目的只有一个——使业务人员在不需要很多计算机的情况下就可以调整系统。
二次开发通常是指客户的业务不能通过简单的客户化实现，需要通过改动程序来完成。二次开发是需要通过改动源程序来完成。这不仅加大了企业的成本，同时也增加了ERP系统的风险，也给系统的升级带来了隐含的风险．需要谨慎选择。
三、企业资源管理系统二次开发的风险
国内企业ERP用户中，调查显示，实施成功率不足30％，出现了ERP的“两难论”，即“上ERP难，不上ERP也难”，为何看起来前景广大的ERP却在国内屡遭这样的命运？事实上，不管是软件供应商还是企业，一般都不希望过多地做二次开发。ERP失败的主要的原因除了管理理念的调整难以外，就是二次开发带给企业难易预料的风险。这些风险主要包括以下几个方面：
升级困难：这是二次开发的最致命的弊端。ERP供应商会阶段性的对系统的不合理模块进行调整，修改部分BUG，公布一些升级的程序，而系统的升级往往只针对标准版的系统。二次开发的维护力量仅仅是部分二次开发人员，而并非整个研发的团队。
破坏现有的稳定性：二次开发对某一局部的更改往往因为没有考虑对全局的影响而殃及整个系统的稳定性，造成整个实施失败。
二次开发的测试不充分：二次开发的测试和试运行时间有限，出现BUG的机率较多。
增加实施费用：二次开发要投入相当的人力物力。软件供应商的技术重点一般都放在ERP系统研发和优化上，为企业特殊需要而配备定制开发和维护人员无疑会增加公司的运营成本。
回款困难：二次开发费用的回款受企业认可度的影响。一旦实施结果不能使客户满意，二次开发的费用就比较难到位，甚至造成项目的延期．影响到项目的关闭。
四、企业资源管理系统的二次开发风险的控制策略
（一）从控制风险的根源入手
对于二次开发风险的控制策略，我的核心观点是，从风险的根源人手。首先构建良好的ERP系统架构。良好的系统架构能够为今后的二次开发奠定坚实的基础。
实际上，系统的架构比功能重要的多。ERP产品不是简单的代码堆积，而是基于模块的组件式拼接。一般客户在选型的时候会刻意强调功能．这也无可厚非，好的ERP产品首先应该有好的功能，但是在做出理性的分析后，就会发现一套好的ERP产品首先应该架构科学，这就是系统架构师越来越走俏的原因。一些以财务著称的ERP厂商很头痛的一件事情就是产品的架构早已搭建完成，很多系统架构，如库表的设计已经固化，很难再去修改、调整，现在增加的模块只能是形式上的调整和增补。不能从系统底层上真正解决问题。这给日后产品的二次开发带来无穷隐患。很多客户在选型的时候误以为只要有系统功能，就能真正满足业务，其实不然，一旦业务有了新的需求，很难从系统上根本解决问题。在具体的实施中，很多项目实施不成功主要是因为产品架构不合理，对于这种情况，无论怎么做二次开发也无济于事。
那么，针对于二次开发的工作，良好的软件整体架构最重要的特征是什么？在实践中我们发现，软件的可扩展性对二次开发的影响最为显著。具体表现在：二次开发的程序能否与整体系统做无缝挂接；二次开发的功能能不能很好地在软件后续的升级版本中正常运用。应该说成功的ERP系统除了内涵先进的管理理念、高效的职能划分、合理的业务流程外，还应最大限度地保留可扩展性。
（二）从二次开发自身的角度控制风险
就二次开发自身而言，包括两个方面的问题。首先，要避免系统不能正常的升级，需要考虑以下三点：第一是数据结构的修改。通常来讲，能够实现完善的二次开发功能的软件，其数据结构的规划一定存在某种规则。标准版本用到的数据库、表和字段的命名方式会和二次开发用到的区分开来，互相之间留有余地，以保证不发生冲突。同时，数据类型的定义要做到完全统一，以保证数据的一致性。如果没有一个明确的规则，必将导致二次开发和标准版本之间互相冲突，这也可能是导致二次开发功能不能升级的主要原因。第二是二次开发功能的实现，应该在不修改父类的原则下进行。增强子类功能，灵活运用继承与重载，以保证后续的版本升级。第三是对某一程序标准功能的修改，最好保存为另外一个与标准程序并列的程序。不要将标准程序完全丢弃，以免升级后的标准程序具备同样或更完善功能时不能得到运用。其次，二次开发要有健会的文档。文档不全或质量不高经常会引发的问题是：前面做好的二次开发，后面接手的人无从了解前面改了哪些，为什么要改，所以无法在原来的基础上继续做二次开发或功能改进。
（三）从行业发展的角度控制风险
从ERP系统的发展趋势看，解决二次开发的风险问题还有两方面的策略：
第一，细分市场。多数企业将目标客户单位的选择由大众市场转向细分产品市场，在这一趋势下，更多软件企业也力争打造细分市场领域的产品优势，以获得更大的成功。从近几年的发展情况看，国内知名ERP软件公司都开始致力于打造自己的烟草事业部就是一个寻找市场细分的典型的例证。
第二，国家标准甚至国际标准的出台。尚未形成统一的开发标准，因而ERP软件的通用性、适用性较差，缺乏选型标准没有统一参照，使ERP市场比较混乱。建立通用式ERP后，还要解决管理软件的通用性与用户需求的个性化之间的矛盾，因此制定ERP行业标准就很必要。这其中对行业数据接口做出统一规定，对于制定ERP标准是关键一步，这有助解决行业ERP产品的研发、实施的规则化、标准化问题。
五、总结
本文的创新之处主要是在控制ERP系统二次开发的风险的研究中，提出了首先要认识“两个项目组”的思路，组建两个项目组的重要性。这是一个认识的过程，也是一个实践的过程。在企业高层的配合下，从问题的根源人手，在开发的具体细节上进行研究，结合用户未来的发展。形成了一套解决问题的策略，从而提高ERP系统二次开发生产力。
