准确的，但是到了项目即将上线的那一刻，会觉得原先的流程有很多多余的地方或者有很多不合理的地方，又要进行更改。如此，就增加了项目的工作量。若只是更改系统的配置就可以实现的话，问题也不大。麻烦的是需要通过二次开发进行更改时，那时间就会拖的比较长了。同时，对项目周期的影响也就比较大。
    这个需求的调整，有多方面的原因。最大的原因大概就是用户对信息化的工作流程不是很熟悉。刚开始需求调研或者流程重组的时候，都是在原先的手工作业流程基础上进行开展的。所以，用户不能正确认识到信息化流程与现在手工作业流程的差异。那么他们就会有先入为主的想法，想把手工流程一成不变的套入到ERP系统中去。结果呢，当真正利用ERP系统的时候，才发现自己的流程跟ERP的流程来好说，是格格不入的，有些甚至是多余的。此时，用户就不得不重新更改流程，而实施顾问也不得不重新调整系统配置与工作流。甚至需要更改原代码。如此的话，项目的实施周期就会延长了。
    所以，为了防止用户在项目即将上线的时候，更改过多的需求，我们应该在项目实施前期，就作好相关的工作，打号预防针。
    一是在业务流程重组的时候，不用空空而谈。有些人业务流程重组的时候，喜欢对着企业的业务流程或者我们提供的标准作业流程，在那边照本宣科的读。而从来不考虑，如此做的话，在ERP系统中是否行的通，或者，中间一些步骤，如审核的步骤是否需要，系统能否帮我们来完成。我个人的建议是，在业务流程重组的时候，即不能脱离用户的实际作业，也不能脱离ERP系统。而应该结合ERP系统，一个流程重组完以后，就在ERP系统中跑一遍。看看是否有多余的动作，是否有需要改善的地方。如此的话，虽然比较花费时间，但是，这可以有效的避免后期需求的变更。因为通过这套工序，用户可能对手工流程与信息化作业流程的差异已经有了一定的了解。如此的话，在ERP上线之前，用户确认的需求与流程的话，可以说是相对稳定的，不会在项目即将上线的时刻，再节外生枝。
    二是我们顾问在对企业进行需求调研或者流程重组以及企业其他的项目实施过程当中，不能说用户想怎么样就怎么样。准确的做法，我认为应该是当用户提出合理需求时，那是最好;当用户提出的需求不合理时，如把原先的手工作业思想沿袭到ERP作业中去的时候，我没要跟用户说明白，为什么原先的手工作业流程不能应用到ERP系统的作业流程中去。在有必要的时候，通过系统的演示，让用户明白，如此做，对于ERP系统来说是不合理的或者是多此一举的。其实，这么做的目的只有一个，就是在项目上线之前，用户的需求尽量都要确定下来，不要有什么改变。因为有时候用户可能只是一句话，但是，对于我们来说，要进行系统的调整甚至是二次开发，工作量是非常庞大的。所以，为了最后项目顺利上线的需要，我们在前期，还是需要花一定的时间，跟用户确认需求与流程。
    三是在可能的情况下，不要因为一下二次开发的需求而影响项目的周期。有时候，到了项目该上线的时刻了，可能有些二次开发的需求还没有完成。但是，项目上线的时机已经具备了。这个时候，我们没有必要因为局部的需求而影响到了项目的上线时机。我们可以下把项目上上去，等到新的二次开发完成之后，在进行升级更新。虽然此时，升级更新会比较麻烦，因为关系到原有的数据。但是，个人认为，这点麻烦还是值得的。毕竟项目若延期的话，对于用户的积极性会有很大的打击。很可能因为这个延迟，而导致我们ERP项目第二期工作不能得到员工的鼎立支持。这个后果我个人认为，比系统的更新升级带来的麻烦更加严重。
    ERP系统是以需求驱动的，需求的频繁变更肯定会给项目的实施带来巨大的影响。所以，要保证项目按时上线，那我们实施顾问就要跟企业用户一起，努力保证企业用户需求的稳定性，不要随意变更。即使有时候在迫不得已的情况下，需要变更的话，也要采取积极有效的措施，把这个变更对于项目上线的影响减到最少。要通过一切有效的手段，保障需求在系统模拟运行之前就一一确立下来。

    项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html