回头看看，行业内对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优化项目时，要对客户提出的果决的需求问题点，进行初步分析，以此来评定工作量以及合同细节，以免项目真正开展起来，出现如案例所述的时候，互相抱怨，进退两难，赔了夫人又折兵，最终做了客户不满意的项目。同时，从行业分工来讲，顾问公司具备优质资源，也应该承担把握项目方向的主动权。
原文网址: http://www.chinasie.com/newsie/zyjj_view.asp?id=416
一、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优化项目时，要对客户提出的果决的需求问题点，进行初步分析，以此来评定工作量以及合同细节，以免项目真正开展起来，出现如案例所述的时候，互相抱怨，进退两难，赔了夫人又折兵，最终做了客户不满意的项目。同时，从行业分工来讲，顾问公司具备优质资源，也应该承担把握项目方向的主动权。
原文网址: http://www.chinasie.com/newsie/zyjj_view.asp?id=416
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25533643/viewspace-690624/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/25533643/viewspace-690624/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
