须执行变更控制流程，否则自担变更的代价;而企业用户，也可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按双方预定的规道行驶，互为制约、协调，避免再发意外。
验收与发现、检验需求并举。大型的ERP项目不少是边实施边验收，然后再发现新问题新需求，再进一步返工完善，一步一步地把项目向前推进，但许多中小型的ERP项目最好是成功切换后，录入一个月以上的企业重要数据，上线运行一个月时间，看看有没有出现新问题、新需求，如没有就可进入验收、签案。毕竟一个月才是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。如ERP系统能做到平稳运行一两个月以上，能够准确导出各类月度报表的时候，系统应用和各项业务操作基本正常、顺畅，通常而言，可认为系统已达到的效果或者是达到了先前预定的目标，也说明企业不再有管理流程、业务流程新需求与变更了，系统项目可算上线成功了，可以放心验收、签案了。
3、项目需求变更的几项须注意事项
充分交流、协商。变更管理的过程很大程度上就是用户与开发人员的交流过程。软件供应商项目经理、技术经理必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发方应郑重向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果，全面权衡轻重。
区别对待，折衷求同。随着项目不断进展，不少企业用户会不断提出一些在项目实施组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。
新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的重要依据。如遇到有些需求无法在短时间内解决、需要花个把月才能解决的时候，那就不要硬拼，不要让项目因此僵住，而要通盘考虑一下，有否临时的折中方案可以先“应付”一下?如让用户先使用现有系统，等过一段时期，技术解决或二次开发成功后再给用户免费升级安装。
项目越接近收尾阶段，再进行需求变更的话，给甲乙双方造成的损失则越大。因此需求变更要趋早，早提出早好。若你项目快要完工时，才发现原先的需求有纰漏、缺失，需要变更重设时，那损失就会大了。建房子，若在房子快造好时，却发现原先设计不对，需要推倒重来，那成本与时间的浪费就大得不得了。