ERP二次开发的多与少

ERP二次开发的多与少企业的ERP系统必定是管理系统，管理系统并不能仅仅通过IT的力量就可以成功的，ERP的二次开发也是为了服务于此管理系统而为企业的管理目标而服务，如果离开这个目标是一味受制于业务部门的需求，只会使ERP这个管理系统越来越难以管理，最终造成管理的混乱而不是提升。ERP系统的开发一直是大家争论的焦点，到底应不应该开发？开发的量多少才算合理？不主张开发的认为：ERP系统是结合了业界先进的业务流程经验，是最佳的业务实践，建议尽量使用系统的标准功能来提升企业的管理水平，另一种观点是：ERP系统先进的管理经验以及业务实践需要借鉴，但同时，不同企业有其自身的特点，通过开发符合企业特点的功能，可以提升业务人员的效率。在此，笔者不敢妄加评论那种观点是否正确，先跟大家分享一下，前几天在一个讨论会上，一个企业IT主管提出的烦恼：A公司实施OracleERP系统已经有好几年的时间，而且也通过实施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二次开发招谁惹谁了？作为一个实施顾问，我看到的很多企业成功了。他们早就成功实施了oracleERP很多年，根据企业发展需求有的已经在标准功能的基础上，又成功二次开发了高级排程、高级备料系统，几经耕耘并且还在继续优化流程。我认为，我们是时候来思考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天以后立即上线。当时我