我们所说的项目实施，就是把客户的需求通过软件系统来实现，而实现的前提却又是对客户的需求有相当的了解。在这一方面上，一个主要的途径就是通过项目调研来获得。一般项目初期的时间比较宽裕，也是为了让实施方的顾问更好了解客户的业务状况，更好地制定蓝图和系统配置，为客户量体裁衣地做出系统的解决方案。当然了，对需求了解的程度，或者对一个项目的需求了解程度的评分是很难评价的。

　　在做项目的时候，实施顾问都会有一个概念——把握和引导客户需求，如果客户的需求从开始到最后，一直都在往外冒，一直都在提出，那么系统的配置就会不停改变，都必需要去迎合新需求去变化。

　　我们还认为，没有需求的客户是最可怕的，他们原来一清二白，什么都没有。那么他会让你给出建议，建议来之于其他同行业，或者顾问的行业经验。东西都是挺好的，可是拿到客户这里，就需做一些改进和变化，这个变化过程是比较不可控的，延伸出去的内容会越来越复杂。站到了别人的肩膀，就会想比别人更高。那么对应的实施难度就会更大。

　　还有部分的实施方，会在需求的处理上，参杂一些糊弄的方案，说ok了，或者说这个逻辑实现了，当时，客户是很难能够测试出来细节的，那么只有等到以后具体使用的过程才能发现，更多的可能是，客户发现这个需求的实现逻辑有问题的同时，也发现这个需求没有当初想象的那么有价值，即可放置不用了。

　　有的人在企业工作了很长时间，但到了做系统的时候，就会出洋相了，平时在业务部门是叫的嘎嘎响，到了ERP，对这三个字母的理解就是那么点皮毛，平时还得顾及部门的业务管理，每每进到项目组的会议的时候，就是胡搅。我这个需求怎么怎么样，那个需求怎么怎么样。而实际上都是八年没遇到过一次的需求，或者这个需求根本就不能按照他那种人为的解决思路去处理，系统已经按照基本的会计准则或者商业规则做了解决，但与他们的实际操作不符。那么实施的怎么办?由此可知，需求是一条实施项目的主线，我们都在围绕这条主线做项目，作为客户方的业务上的骨干，如何提出干净利索的需求，也是个大难题。

　　因为软件系统的功能毕竟是固化的，所以顺利完成的项目，肯定是在需求做的好，需求做好了，那么解决方案就优了。