企业的ERP系统必定是管理系统，管理系统并不能仅仅通过IT的力量就可以成功的，ERP的二次开发也是为了服务于此管理系统而为企业的管理目标而服务，如果离开这个目标是一味受制于业务部门的需求，只会使ERP这个管理系统越来越难以管理，最终造成管理的混乱而不是提升。

ERP系统的开发一直是大家争论的焦点，到底应不应该开发？开发的量多少才算合理？不主张开发的认为：ERP系统是结合了业界先进的业务流程经验，是最佳的业务实践，建议尽量使用系统的标准功能来提升企业的管理水平，另一种观点是：ERP系统先进的管理经验以及业务实践需要借鉴，但同时，不同企业有其自身的特点，通过开发符合企业特点的功能，可以提升业务人员的效率。在此，笔者不敢妄加评论那种观点是否正确，先跟大家分享一下，前几天在一个讨论会上，一个企业IT主管提出的烦恼：

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开发前，必须进行规划，确认此开发是否对企业管理有所提升，是否有利于业务流程的顺畅。同时开发是服务于流程提升，因此开发并不是越快越好，必须在开发的质量与可维护性有所保障的基础上追求开发效率。

ERP二次开发的‘知’与‘行’

回头看看，行业内对ERP二次开发的声讨10年由来没有停止过：有过一种思潮说ERP标准功能代表行业最佳实践模型，没必要二次开发，遵守学习就行了；又有过一种思潮说ERP实施是给客户提供最佳解决方案，该开发时就开发；再有过一种思潮说我们现在倡导ERP实施过程按需求开发会使ERP变味，我们要停止开发…ERP二次开发招谁惹谁了？

一、ERP二次开发招谁惹谁了？

芒果累满枝头的季节，刚好验收一个ERP二次开发的项目，经历了半年的项目终于要关闭，再一次感到一段新奇历程结束时的喜悦。于是拿起电话打给一个朋友，他是东莞一家服装制造公司IT主管，手头也正在进行着ERP库存模块的优化项目，他在电话里抱怨这次优化成果刚刚上线，修改后ERP系统很不稳定，每天都在救火，不是搞乱了数据就是修改效果不符合终端用户意见要返工，完全不能支持最初的流程优化设想，上线以来一直象梦魇。还不住的抱怨工程师们没搞清需求，开发质量差。

挂上电话，我陷入了沉思：不管作为甲方IT还是乙方服务商，最终目的都是为业务部门做好服务，作为ERP实施顾问，我最不愿意看到甲方对项目有如此失望，就好象是自己亲自破坏了他们的ERP系统，导致他们疲惫不堪。回头看看，行业内对ERP二次开发的声讨10年由来没有停止过：有过一种思潮说ERP标准功能代表行业最佳实践模型，没必要二次开发，遵守学习就行了；又有过一种思潮说ERP实施是给客户提供最佳解决方案，该开发时就开发；再有过一种思潮说我们现在倡导ERP实施过程按需求开发会使ERP变味，我们要停止开发…

ERP二次开发招谁惹谁了？

作为一个实施顾问，我看到的很多企业成功了。他们早就成功实施了oracle ERP很多年，根据企业发展需求有的已经在标准功能的基础上，又成功二次开发了高级排程、高级备料系统，几经耕耘并且还在继续优化流程。我认为，我们是时候来思考ERP二次开发的‘知’与‘行’了。

二、开发目标，决策对了吗？

不要过早抱怨技术工程师开发的功能很别扭，挖掘不出（或坚持不了）真正的优化需要，最终作出的开发当然是四不像，这样企业方和服务商双方都有责任。看看以下从真实项目的案例：

一家热水器制造公司生产采购部门领导提出，要减轻采购员下达采购订单的工作量把工作中心转移到采购缺料跟踪上。明确向其IT部门提出需求：由采购部门出资，IT出人主导，要求帮其二次开发批量下达、批量审批采购订单的功能。IT部门在主导立项时，将其定位成明确的批量下达采购订单功能，并且这样的开发被定性为比较简单。企业方任命了2名采购员作为关键用户，这2名采购员对ERP系统非采购模块不熟悉，在项目开展调研阶段，他们认定，自己每天都要花很长时间在系统录入一张张订单，的确耗费不少工作量，开发一个批量下达的功能真的很好。顾问方根据关键用户提出的意见，分析之后认为做到批量下达可行，同时开展了紧凑的开发测试过程。上线后，采购员门望着灵活的批量下达功能，一下子不敢在系统下达订单了。

采购员的工作效率被谁偷去了？最后经过多方走访，发现采购员们每天被采购价格不确定、主计划善变所干扰，每下订单都要重复确认某些物料的价格、询问某些物料的采购计划是否有变化、衡量储备库存要保持多少才好……是这些因素在起关键作用桎梏采购工作效率，一个简单的批量下达功能是无法从根本上解决这些问题的，尽管确实方便了部分人可以通过全选、下达等功能批量下达一了百了，但这显然是不负责任的做法。

根本问题出在：提出优化需求的人，没有把自己的要求明确传递给授权参与项目的关键用户；IT在立项内容中缩小了问题考虑范围，ERP优化不同于一般的小系统优化，往往牵一发而动千军，立项之前首先企业内部没有进行过评估分析，同时IT也有必要站在全局的角度考虑这个开发需求是否合理；顾问在有限的资源支持下，得不到完整的客户需求问题点，更无从分析评估主计划为什么不刚性、供应链管理价格为什么不规范。

二次开发‘知’与‘行’。以上案例中的项目甲乙方，无不互相抱怨，甲方抱怨乙方作为顾问公司没有替用户考虑全面；乙方委屈甲方没有配备正确的用户，没有提出合理的项目范围。既成事实，后悔已晚。让我们来思考如何做好需求决策吧：

a）凡是实施了大型ERP系统的公司，其组织架构必然也比较比较庞大，任何工作流程的优化必然涉及其他部门，不穿越部门壁垒的流程很少，ERP软件的管理思想就是由一组组紧密关联的流程组成，所以在评估需求何调研需求时，企业IT都应该要特别重视ERP二次开发项目的需求调研范围；

b）企业实施了ERP标准功能之后，需要不断自我审查在日后的流程执行过程，是否有偏离，对于不健康的ERP系统运作，何谈优化？因为根本无从下手去优化了，本案例中的需求，调查到最后其实可以通过业务流程规范来解决，可能最后根本不需要ERP二次开发了，这一点必须依靠企业的主观能动性来检讨。不得不重视的是，顾问公司在接到订单那一刻，基本没有太多理由告诉客户说这个项目不用做了，因为当顾问公司给出这样的结论时，是对这个项目立项可行性的质疑，通常情况下，顾问公司不会如此做。除非项目立项之前，企业邀请了顾问公司来作评估分析，这一邀请行为可以成为专门的项目了，因为顾问人天都比较贵，况且企业IT应该承担起ERP系统运作是否健康的监察责任；

c）企业持续培养知用善用人才的很重要。根据多年的项目实施经验，不少企业在最初实施ERP系统时，培养了一批优秀的关键用户，但在后来的建设和维护阶段，因人员流动而丧失了这些熟悉系统原理的人才，我们往往发现很多优化项目中推选的关键用户，其实对ERP系统原理后台的数据逻辑并不清楚，他们只知道操作，出现疑问并不能有效自我诊断和思考；

d）作为顾问公司，在接触到这样的ERP优化项目时，要对客户提出的果决的需求问题点，进行初步分析，以此来评定工作量以及合同细节，以免项目真正开展起来，出现如案例所述的时候，互相抱怨，进退两难，赔了夫人又折兵，最终做了客户不满意的项目。同时，从行业分工来讲，顾问公司具备优质资源，也应该承担把握项目方向的主动权。

三、开发计划，评估对了吗？

二次开发项目的前提范围很大，小小的开发都需要考虑对全局的影响。企业老板不要一开始就强制项目组务必赶工在几月几日时上线，拍脑袋决定的计划恶果最终是要自己买单的。为什么呢？如下是我亲身经历的一个项目：

接到一家空调制造公司供应链部门提出需求，要对供应商使用的供应商平台进行二次开发，目的在于将现有的供应商送货单由单张打印改变成合并打印，以方便为供应商省纸。客从进驻项目第一天算起，客户要求在10天以后立即上线。当时我所处的项目组技术顾问和功能顾问共同研究后，发现20天时间只够开发和系统性测试，没办法安排用户测试和意见反馈修改的时间。但业务部门领导不同意，强调需求非常紧迫，IT部门迫于压力也只能强调按这个目标执行。作为顾问公司，声明了如此工作计划不合理，但是客户感情上不能接受。最终，这个项目以加班的方式赶在20天后上线了。但是上线第一天就发现有一些边缘触发功能不够完善；供应商没有经过严格培训和事前试用，在使用合并打单时有很多问题。导致顾问和企业关键用户都在救火，最后招致IT建设部门领导的批评和最终用户的不满。

抱怨来的时候，谁准备好了？经历了这样一次双方不能正视项目开展方式的项目，所有人都在承受着因计划安排失策，而带来的迫不得已加班、偷工减序等行为。尽管着急上线后，还是要对未完善、未尽职的工作进行补救，但这在ERP二次开发项目中，是非常忌讳的。好歹这次失误只是对供应商平台的影响，如果涉及ERP帐务等问题导致财务出现差错，想必所有人都不好过了。

根本问题在于：双方没有建立互相信任的基础。让我们来思考在有限的合同条款下，双方如何平衡好计划安排：

a）企业希望二次开发越快越好，就要正确面对二次开发类项目的特征：ERP系统涵盖企业最关键的财务、制造、库存，任何改动都必然放在全局范围内考虑方案、安排技术、开展验证，只有准备工作做足了，才能做到万无一失；企业给出此类项目的实现目标中，必须包括‘安全’这一条，以免最后出现四处救火、痛不欲生；相信当企业理解了这一特征后，技术工程师们没有理由降低代码质量（比如可扩展性），实施顾问们没理由不准备完整的测试文档，培训师们没理由不提供详细的原理培训和对应用户掌握程度的测试评估。一切质量都需要时间。

b）企业应该指派具备技术能力的人，对二次开发项目行驶监督职责。项目计划安排决定了整个项目工作安排的质量，企业一方面希望通过缩短时间来督促顾问方尽可能多的做足准备工作，另一方面又担心因开发技术过于专业而无法监督。其实，二次开发项目与普通的项目具备大多数共通因素，只是开发和测试环节技术专业性较高。因此，企业希望实现深度监控，完全有必要指派具备技术能力的人全成跟进，已解决后顾之忧。

c）顾问公司在任何危机条件下，都不能放弃项目质量。本案例中的上线结果有惊无险，如果涉及重要的企业资料，那顾问公司就不仅仅是承担项目延期罪名了。面对每一家客户对优化需求的迫不及待，顾问公司完全有必要给出全面细致的WBS分解，让客户了解每一项工作安排的必要性。相信企业不会认为，因时间要求紧迫，可以不开展必要的用户测试，可以不开展必要的用户培训，可以不开展有安全保障的模拟上线，要知道这几项工作虽然组织起来麻烦，但却可以事半功倍。

四、项目控制，执行到位了吗？

ERP二次开发项目与常规的项目在控制方面，都是共通的，项目管理的9大知识体系无须多言。在此只谈几项致命的要素，通常是这些因素导致大家常说的，很多二次开发的功能最后用不起来了。让我们看看在执行过程如何控制：

a）性能优化问题：很多ERP二次开发项目，都会忽视新开发功能的性能问题。因为ERP标准功能作为成熟产品，必然经过产品公司强大资源在各方面的测试，建立了合理的性能优化机制，合格后才卖给客户。但往往在经历几次二次开发之后，系统运行更慢了，甚至莫名其妙的down机。最关键的原因在于，开发是建立在一个庞大的技术框架内，技术顾问们最关注功能是否可以正常使用，但忽视新功能的数据增长模式，在项目完成的1－2个月内，性能尚可，经过1年半载的应用，往往出现疯狂的数据增长而导致系统性能损失。企业IT维护部门必须正视这个问题，需要将其作为ERP二次开发要考虑的基本点。而顾问公司方，也往往会很容易提供性能优化的机制。

b）延伸影响问题：此处指的延伸问题，是指与被二次开发功能点具有流程关联性的其他功能点。此类问题往往是上线之后救火的重点，其特征是：其不直接与优化功能点关联，非常隐蔽；其数据操作特征肯能受优化功能的影响，比如上游数据格式变化可能对下游某个点有影响；其与被优化功能点属于相同业务实体，只是别人变而自己不变，此时很可能央及自己。对于此类问题，首先期望在方案阶段可以考虑到，但方案阶段往往不考虑这些细节，实际执行过程大多通过测试来接触影响。因此，二次开发的测试工作是整个工作中浓墨重彩的一笔，不要总是怪技术顾问想得不周到，范这些错都是在情理之中的，要有这种意识就可保上线后无须四处救火。切记切记。

ERP二次开发是否会妖魔化原有功能，这完全取决于双方对开发策略的定位，是否准确；二次开发工作是否会因各种不成熟因素而催生成畸形，这完全取决于双方对二次开发的典型特征的认知；二次开发功能经历了时间考验后，会不会变成累赘或多余的东西，这完全取决于在项目执行过程的控制是否到位。

知与行，行与知。让我们谨记。

客户化开发风险分析及对策

在项目实施过程中，客户化开发工作主要关注的应该是客户方和开发方如何配合，既保证为客户方提供正确指导，又能使开发方充分考虑项目潜在因素及对风险的控制。使客户方和开发方能达到利益最大化为目的，实现共赢，走向成功。

现代企业面对激烈的竞争，信息化被越来越多企业所采纳，但实施信息化的过程中为了满足企业特定的需求，需要对企业进行客户化开发，但进行客户化开发的过程中也伴随着一定的风险。那么如何合理的规避企业风险，使企业能顺利的开展信息化工作，并最终通过信息化来全面提高企业的效益，提升企业的竞争力？本文想从客户化开发角度阐述一下企业信息化实施过程中如何规避风险的问题。

客户化开发的成因和风险

客户化开发的成因主要有两个，其一，软件产品是商品化软件，属于行业通用型软件，而每个企业还是有其自身的特点，既要吸纳管理软件中的先进管理思想，也要保持企业的特色，因此需要对于原来的软件进行客户化的修改。其二，随着项目的实施，客户对信息系统有了更深的了解，应用不断深入，对信息系统产品就会提出更多的要求，这些要求就形成了客户化开发的另一来源。客户化开发在满足客户实际应用的特殊性需求的同时，也会给实施工作带来了巨大的风险。纵观失败的信息化实施项目，因客户化开发导致的延期比比皆是。没有节制的客户化开发工作是导致项目失败的重要原因之一。客户化开发风险主要体现在如下几点：

一、实施过程中，对于需求，客户方与开发方只有口头的交互，没有正式的确认文档。这样做可能产生歧义，客户和实施顾问对需求的理解不一致，做出来的东西不符合客户方需要，使开发成果与需求产生偏差，客户方无法使用，开发方白白浪费时间。

二、随着开发的进行，客户方需求不断增加或变更，开发方尽力满足，导致形成一个需求黑洞，整个项目组陷入到需求黑洞中，客户要求的合理性无法衡量，开发方工作不被认可，致使项目偏离初衷，无法为企业提供指导与帮助。

三、开发方没有对需求开发过程进行严格的监控与跟踪，对项目进度影响较小的变更不做监控，产生积累效应，可能对整个项目的产生影响。

四、开发方评审工作不到位，使一些看上去无关紧要的修改与其它系统产生关联错误。

五、现场的更改没有记录，包括变更的原因和变更的内容，使客户的升级工作变得非常困难。

所有的这些风险都对项目的进度、质量和成本产生不同程度的影响，给实施双方带来严重后果，浪费了时间和精力，资金遭受损失，只以失败告终。可这些风险又不能完全避免，我们需要一些手段来控制。

客户化开发问题对策

站在项目实施的角度上来看，项目实施顾问一定要按原则办事。给客户开发一个功能，修改一段程序看似比说服客户放弃修改的念头容易得多，因此实施顾问宁可埋头做程序而不愿意说服客户，其中隐含的风险却往往被忽略，这种做法是对客户和公司的不负责任。项目实施顾问应在充分了解客户需求的基础上做出正确的判断，正确引导客户，如何使用系统现有的功能满足需求。

对于必要的客户化修改工作，可以从需求开发和需求管理两个方面来达到对客户化修改工作的控制。

需求开发过程包括需求收集、需求分析和需求的评审过程。需求收集一般在项目签订前就会有概要的了解。项目启动后，对企业情况进行调研，详细的了解企业中各部门的情况，收集客户需求，分析企业的现状以及可能会产生的客户化开发工作，出具调研报告。对于实施过程中，客户方提出的需求，无论大小都应形成文档，经信息中心人员收集、整理、分析，最后总结归纳后，经对方负责人签字确认方可。需求收集后，实施顾问就要对客户的需求进行分析。需求分析的内容主要是清晰客户提出的需求是什么？为什么会提出这样的需求？明确需求产生的根本的原因。需求分析工作还应该包括需求变更对项目整体计划是否产生影响？是否需要重新调整资源配备等项目管理上的问题。需求分析完毕后必须经过评审。评审作为一种有效的质量控制手段，是软件行业多年的开发和实践总结出来的。参加评审的实施顾问必须对需求规格说明书中提出的内容做出正确的判断，决定是否按照说明书进行开发，将需求开发对项目产生的影响作相应的评估，排出优先级。针对不同情况应该通过引导和制度来规范评审环节。无论是否经过技术委员会评审，项目组都有责任将需求及工作成果进行反馈，作为后续开发的依据。

需求管理主要是对需求变更的过程的跟踪和监控。对于项目而言，也许客户每次提出的需求都是小需求，但是经过不断的积累，也许就对项目整体产生了较大的影响。质量管理人员可以通过实施顾问的工作日志及客户的反馈中发现客户的问题及意见，跟踪实施顾问，将客户的需求录入到公司的管理环境中。项目负责人根据实施顾问提交的反馈意见，及时发现需求变更过程中的风险，对项目整个实施周期内的需求从全局角度进行监控，并及时制定合理的措施，防止需求变更对项目产生影响。