ERP二次开发项目交付过程图：

   

    其中发起项目开发人员属于版参与状态，其他流程均保障开发人员全程参与。     所谓的二次开发，是基于标准产品上来说的，基于标准产品有利有弊，利：更多的代码可供我们参考。弊：必须以标准产品为基准，限制条件过多，不利于单纯以技术为职业规划的开发人员长期发展。     适合人群：瞎搞搞。     我们的客户每一家都不一样，都有各自的特点，如果遇到有专业IT部还好些，如果没有那么效果会差些。有专业IT部，客户就会知道标准软件开发的具体过程，初步知道个难易程度，会为开发人员着想。 没有专业IT部的客户，只有不停的让你赶进度，他看具体结果，管你用啥方式方法。     一般的ERP项目的立项要走很久的流程，一般1--2个星期甚至更长时间，具体看客户了。     成功交付项目应注意的几点：     1. 需求调研要不耻下问，要脸皮厚点，问题多点，记录多点。在客户拿不定需求点时，我们要体现出专家的一面，让客户做选择题，而不是填空题，对于客户的需求实现有难度并且工期还紧的情况，我们邀想大禹治水一样，不能堵，堵是堵不住的，要疏导，把需求引导到我们可以解决的方向去，如果时间允许，打开他们原有系统看看流程，深入了解一下，做一下参考与改进。在每次与客户沟通需求的时候，有准备，前期做好问题列表，针对客户的回答做好笔记，回去整理，一定要当天整理，我相信你的记忆力没有那么好，不要太过自信。整理好之后及时发给项目相关人员及客户负责人，一定要让你的团队成员参与进需求调研上来，记住你不是一个人在战斗。     2. 项目估算要让销售等一线人员和客户理解你为什么要评估这么多天得工作量，尽量要把明细给到他们，堵住他们的嘴，好的项目估算是建立在良好需求调研的前提下的，盲目的估算，会给你后面的工作带来灾难性的打击。适当的时候可以与同事一起头脑风暴一下，做一个原型给客户看看，再配上流程图。有以前的项目可以借鉴，或者是标准产品上的内容是否有可以借鉴的，这样评估的工作量会精准些。生活中不缺少美，而是缺少发现美的头脑。     3. 项目开发要稳重，不能着急，即使是客户很急那你也不能着急。理顺好123条，把相类似的功能分配给同一个人做效率会高些。在流程方面一定要与实施人员沟通好，毕竟开发人员对标准产品的了解不如实施人员，某一流程可能只需配置就可以搞定，就没必要去开发。代码的耦合一定要做好，为后期变更做良好的准备。开发团队一定要有自己的开发空间，比如单独的会议室之类的，免去客户打扰。去客户现场开发有利有弊。利：沟通方便，及时快速。弊：客户需求变更多，你去做的工作可能会增加，有问题就找你。权衡一下才行。ERP项目需求变更就像吃饭一样平常，前期要预计好，项目变更可以，但要有个流程，我们都是要培养与客户的关系，小的需求适当免费，大的需求必须要收费，变更过程要有流程，必要时需要双方领导签字或者开会确认，最好一个月提供一份需求变更单明细给到双方领导，这样需求才可能得到有效控制。     4. 项目测试要结对，团队内部互相测，避免一个人从开发到测试等，互相做代码走查及功能测试，改进的过程很重要，因为客户已在实用ERP系统，改进过程一定要及时准确，这样就像前面我们说的代码耦合性一定要做好。不要给客户不良的印象。尽量避免上线后出现NullPoint 错误，很低级。     5. 上线验收要蹲点客户现场，及时的给客户讲解操作过程，最好做培训，防止客户误操作带来的影响。     一个项目的成功需要很多人的努力，我们要把目标锁定，加强沟通，能当面沟通的尽量不要打电话，能打电话沟通不要mail，mail只做备份用。项目成功涉及很多部门的合作，这个要看公司体制啥啥样的，是以项目为中心还是以盈利为中心的，杜绝部门间的内耗，内耗害死人啊。项目的成功是最好的结果就是公司与客户实现双赢。

本文出自 “” 博客，请务必保留此出处