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

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