上个月，我的一位曾经在ERP“圈子”小有名气的同事突然宣布从此离开ERP行业，转向传统行业，此举让所有“同窗好友”大为不解和遗憾。该同事不是业务不精，也不是脆弱之人，而是一位有着6、7年ERP系统经验的高手(毕竞真正的ERP在大陆发展也不过十年左右)，在其惊人之举背后，竟然牵扯出在目前ERP行业中的一些无奈现象，比如此次讨论的ERP项目与二次开发问题。在ERP圈子里实施项目超过5年的朋友都会发现，现在的ERP项目是越来越难推销，同样也是越来越难实施。正如这位同事所说，做了这么多年的ERP项目，觉得还不如去卖一个杯子，杯子卖给了客户，客户会立刻付款，几乎没有什么售后的问题，而ERP产品则完全不同，把软件卖给客户，如果不能实施好，客户等于买了张光盘而已，而实施ERP又往往难度很大。虽然几乎所有的ERP厂家都会向客户承诺很容易实施，但是在ERP项目圈子中的很多实施顾问的工作状况并不乐观，往往被项日实施过程中各种各样的业务需求折磨得“死去活来”，这也是ERP圈子里顾问流动率高的原因之一，因为项目实施不利，不得不离开，另寻东家。对于实施顾问来说，寻找到一个产品架构好的ERP产品的确至关重要。
　　
　　ERP系统架构比功能更重要
　　
　　ERP产品不是简单的代码堆积，而是基于模块的组件式拼接。一般客户在选型的时候会刻意强凋功能，这也无可厚非，好的ERP产品首先应该有好的功能，但是在做出理性的分析后，就会发现一套好的ERP产品首先应该架构科学，这也就是很多软件公司愿意花上百万元重金聘请系统架构师的缘由。一些先前以财务著称的ERP厂商很头痛的一件事情就是产品的架构早已搭建完成，很多系统架构，如库表的设计已经固化，很难再去修改、调整，现在增加的模块只能是形式上的调整和增补，不能从系统底层上真正解决问题，这给口后产品的二次开发带来无穷隐患。很多客户在选型的时候误以为只要有系统功能，就能真正满足业务，其实不然，一旦业务有了新的需求，很难从系统—上根本解决问题。过去企业只需要关心财务信息化——能定期出财务报表即可，随着业务的发展，企业信息化的初衷发生了质的飞跃，刊在由财务一体化向“企业ERP数字神经”的管理思路转变，企业上ERP的目的变成了管理企业所有的资源，比如制造企业梢重心放在了对制造业务的管理，同时向进销存延展，则务只是最后业务数据的归集而已。但是如果反过来管理，由则务开始，然后再去管理制造业务，则不论从数据的准确性还是业务合理性来看都是不科学的。所以一套好的ERP系统首先应该架构好。在具体的实施中，很多项目实施不成功主要是因为产品架构不合现，对于这种情况，无论怎么做二次开发也是无济于事。
　　
　　客户化与二次开发
　　
　　客户化和二次开发是两个容易搞混的概念，客户在项目的实施中对此往往不能很好的区分。从工作量和难易度看，客户化远远小于二次开发。好的系统尽量提供系统参数，通过参数配置(Configuration)来满足客户业务需求，而不是动辄就通过写代码完成，这样做的好处是实施速度快，对系统没有仟何伤害，系统升级非常容易。一套ERP系统的优劣从参数数量上就可以区分。灵活的参数设计可以让客户通过参数的自山组合来满足复杂的业务。随着IT技术的发展，现在各ERPV商都在系统功能自定义、报表白定义等方面大做文章，目的只有一个——使业务人员在不需要很多计算机的情况下就可以调整系统。二次开发通常的定义是：客户的业务不能通过简单的客户化实现，需要通过改动程序来完成。二次开发需要实施双方都有相应的IT技术人员参与。联想集团在实施CRM项目时，仅二次开发就配备了多达15名代码开发人员，这些人员邢来自于联想内部，而实施方人员仅有2、3名。这么做的原因一是降低费用(顾问费过高)，二是加快实施进度。目前很多国内企业在实施ERP项目时，向供应商提出了很多二次开发内容，自己几乎没有配备开发人员，项目实施进度非常之慢。既然是二次开发，就需要ERP厂商捉供二次开发的工具和开发文档，例如ERP产品的详细设计文档。通过查阅设计文档，开发人员可以清晰地看出库表字段、业务逻辑(Business Logic)、判断语句等，而这一点并不是每个供应商都有能力提交出来的。
　　
　　二次开发与报表自定义
　　
　　ERP系统包括单据、单据处理和报表管理。不论财务、进销存还是生产管理，首先是提供大量的表单(Form)让客户填写，这些表单又称数据入口。好的表单应该对应复杂的库表设计，即这些表单的库表有足够的字段，包含多种自定义字段等。其次是单据的处理，数据流入系统后，需要系统根据预设的逻辑进行处理，在好的系统中，该逻辑层属于继承(Inherit)式搭建法，即如果客户需要调整该逻辑，可取消原有系统内置的逻辑继承关系，取而代之的是为客户二次开发的业务逻辑。最后是报表处理功能，现在一些ERP系统提供管理驾驶舱(Pilot)，即把很多业务报表通过页面设计用一个页面显示出来，使管理者可以随时看到各种管理数字以“仪表”的形式显现。管理报表的合理使用是实施ERP的重要收效之一，如成本是通过成本报表显示的，库存呆滞情况是通过存货呆滞表查看的等等。其实客户的部分所谓二次开发需求可以通过自定义报表功能来实现，而根本不需要修改源程序。只要该有的数据能及时收集到系统，后期的各种提取分析都不难实现，只是实现的方式有所不同。在ERP项目的实施中，可以向客户推荐通过报表来实现客户的一些业务需求。当然这需要ERP厂商提供功能完善的自定义报表工具。有些报表开发工具是ERP厂商自有的，也有一些由第三方提供。
　　
　　建立二次开发的规范
　　
　　二次开发是一项庞杂的系统工程，决不是简单系统代码的增增减减，应该按照IS09000和知识库管理(KM)来进行，开发人员CheckOut (登记出)源代码时，其他人员不能再修改该支程序，被修改的程序应该及时Check In(登记入)到系统中进行编译。二次开发的文档应该由专人保管，而代码注释也必须清晰易懂，还必须有专人负责检查代码质量。新扩充的字段命名、新建程序的命名都应该由专人分配，首先不能和现有系统冲突，同时还应预留一定的空间。对于公用元件一般不建议修改，因为公用元件被很多程序调用。在程序的编写上应采用继承的方式，在保证不破坏原有功能的基础上做个性化的功能完善。如要修改处理业务逻辑，则分两种情况：一是修改原有程序中的处理逻辑，将局部的继承去掉，重写新逻辑。二是在原有功能基础上新增，保留继承关系，在新的子文件中只完成新功能的实现即可，当版本升级时，二次开发的程序惟一要做的就是继承新版本的Source(源代码)做重新编译。
　　
　　有所为，有所不为
　　
　　这句话一直是笔者想真诚送给所有ERP客户的，它是原神州数码管理系统有限公司副总裁刘岳晖在负责联想ERP项目时说的一句话。这句话的份量非常重，也包含了很多项目管理的哲理，充分体现了项目负责人的管理大智慧，它所传达的概念是如何权衡(Balance)实际业务需求和系统内置功能之间的矛盾、项目进度和业务需求范围之间的矛盾。二次开发毕竟是有风险的，一是会造成项目时间的延误，二是增加系统日后升级的难度，三是可能会破坏系统现有的稳定性，四是客户的实际业务需求一旦放入ERP系统后会出现“业务陷阱”，客户过去的业务往往由手工操作，或是“信息孤岛”，而放入ERP系统后很多业务逻辑会发生很大改变。因为，客户在决定是否做二次开发前，一定要认真权衡，对比分析，究竟是ERP内置功能改变现有业务思路，还是改变ERP系统逻辑，即对二次开发的必要性、效果和风险做到心中有数。在大量ERP项目失败的案例中，一些客户项目负责人过于强势，要求ERP厂商必须严格按照现有业务逻辑修改系统，完全不考虑项目进度、项目开发风险、ERP厂商的工作量等，结果造成双方关系十分紧张，项目也没有如期完成，很多所谓的“二次”内容也是补丁套补丁，系统十分不稳定。客户在分析业务逻辑时，是基于独立分析客户某一业务模块，这往往有悖于ERP系统的标准化设计，ERP系统是基于多模块之间标准的耦合关系，将一些标准的业务进行标准化处理，固化到系统中，才能保证数据流、信息流、资金流等的集成和合理流动，而这一点客户是很难区分和理解的。所以项目负责人在发现一些特殊的业务需求时，一定要谨慎处理，合理决定二次开发的范围。因为ERP实施的最终成功不是一个点、两个点的成功，而是整个业务流的成功。