在CRM项目过程中，需求调研是一个必不可少的环节。不过根据笔者的观察，很少有企业在这个环节做的到位。简单的说，企业在这个环节容易走两个极端。一是完全根据现有的操作来定义需求，没有考虑到未来的变化与发展趋势。另外一个极端就是分析需求是太过于理想化，没有考虑到企业的实际情况。正是由于这两个极端的现象，才导致不少企业的ERP项目或者以失败告终，或者难以达到预计的效果。那么企业该如何来避免这两条极端路线呢?笔者下面的这些建议或许多各位读者有所帮助。
一、 以现有流程为基础进行需求调研
笔者在进行需求调研时，第一个工作就是让企业整理现有的跟CRM有关的流程。通常情况下，有条件上CRM项目的企业，在管理上往往有了一定的水准。在企业内部，一般都已经有一套比较完善的企业管理制度。这其中就包括操作流程。而CRM系统其本质就是流程驱动的。为此企业现有的CRM管理流程对于我们需求的整理就显得尤其的重要。所以笔者第一件工作就是查看企业现有的管理流程。在这个环节中，主要要注意如下内容。
一是流程要细化。有些企业虽然已经有了比较书面化的管理流程，但是线条太粗。如笔者以前碰到过一家企业，他们已经实施了ISO。通过ISO项目帮助企业建立了相关的流程。可惜的是，这些流程的线条很粗。如销售接单就一个流程。实际情况是，销售订单会分为赊销订单、预付款订单等等。根据产品的性质不同，还可以分为新订单和返工订单等等。根据订单性质的不同，后续相关的操作也不同。在CRM系统中的操作也有所差异。为此在收集客户现有的流程时，要注意对流程的细化。如果客户的流程比较粗，还要求客户根据实际情况，对流程进行细化。这有利于后续系统的配置与调整。
二是流程要与企业的实际操作一致。企业的实际操作可能不规范，需要在后续工作中进行调整。但是在需求调研阶段，一定要注意，项目管理员收集起来的流程，要能够反映企业用户的实际操作。简单的说，在需求调研阶段我们并不太过于关心用户的实际操作是否符合规范。我们关心的是用户现在到底是怎么操作的。根据笔者的经验，即使管理很完善的企业，用户也不会百分之百的去按照流程来办事。为此在流程收集时，需要向用户多问一句：实际操作跟这个流程有差异吗?如果有差异的话，那么差异在哪里?在这个环节中，不要去一味的责怪用户没有按流程来办事。否则的话，用户很可能不会畅所欲言。
三是流程应该有关键用户过目过。笔者在做项目时，有时候流程是企业的稽核部门或者管理部门提供的。虽然他们能够提供比较完整的流程，但是笔者认为，为了后续项目能够顺利开展，项目管理员在这里不能够偷懒。应该拿着这些书面流程，给关键用户进行确认：这是最新的版本呢?这能够反映他们的实际操作吗?这一步确认的动作，其目的也主要是分析企业所规定的流程与用户的实际操作之间的差异。因为在CRM流程重组过程中，可能需要对企业现有的流程进行优化与重组。要做这项工作的话，其前提就是要知道企业现有的书面流程与实际操作之间的差异以及原因。
二、 需求要适当超前，但不能过走极端
在需求调研时，除了要关注企业现有的实际操作之外，笔者认为还应该适度的超前。如果上了CRM系统之后，企业所做的客户关系管理还只是停留在原有的范围，那么即使CRM项目上线了，也不能够给企业带来多大的价值。为此一个负责任的项目管理员，会提醒企业，在需求整理时要考虑到未来两三年之内的需求。这对于系统的配置、基础数据的整理等等都有很大的帮助。具体的来说，可以从如下几个方面展开。
一是可以从系统的角度出发，来分析企业未来的需求。有过CRM经验的用户，都会有这方面的感受。有些CRM管理模型，很难通过手工管理来实现。而需要通过系统的帮助，再加上恰当的管理，才可以发挥效益。对于这些需要依赖于信息化系统才能够实现的需求，在项目过程中需要特别关注。因为以前由于技术方面的限制，用户基本上不会涉及这方面的内容。而以后上了CRM系统之后，这方面的需求就是顺理成章的事情。这些需求就很可能是企业未来所需要的需求。故无论是项目管理员，还是实施顾问，在需求调研时要同时去关注系统的功能。以判断未来发展的需求。
二是听听关键用户的声音。关键用户往往在CRM这个领域内具有比较丰富的经验。有些甚至在学校里受过专门的CRM相关的培训。可能由于种种方面的限制，他们所希望实现的需求难以完成(有些是上面第一点所说的技术上的限制，另外有可能是平时没有决策的权利)。此时这些关键用户正可以凭借CRM这个项目平台来展示自己的才华。他们会把自己的理论知识转化为实践。他们提出来的需求，就有可能是企业未来可能需要实现的内容。不过这里需要注意的是，不要纸上谈兵。虽然这些关键用户受过正规的教育，也了解企业的运作，但是有时候仍然会犯教条主义的错误。此时实施顾问就要与这些关键用户进行沟通，以判断这个需求实现的可能性与必要性。
三、 需求要有书面的报告
在需求调研的时候，笔者向来强调书面报告的重要性。其实我们在日常工作中，都会有这方面的经验。当我们提建议时，口头的内容很可能是大脑的第一反应，而没有经过深思熟虑。相反，在会后将口头的内容进行书面化的过程中，会对这个第一反应再次进行消化分析。在这个消化分析阶段，考虑的内容会更加全面一些。有时候第一反应的内容经过消化分析之后会觉得不合理。有时候可能会认为需要进行进一步的调整与优化。总之口头的内容经过书面话之后，在质量上会有很明显的改善。
首先，当用户口头提出需求时，可以进行适当的纪录。然后跟用户进行分析讨论。注意分析讨论完毕后，一定要让用户在提交一份书面的报告。报告的内容越详细越好。如需要包括提出这个需求的背景、现有的操作模式、如果按这么操作以后可能带来的收益、对其他用户的影响等等。
其次，项目管理员最好做一份格式化的文档，让用户根据文档来填写相关的内容。如可以在A4纸上根据需要做好相关的格式。如需求提出者、部门、原因等方面的内容。格式越详细越好。如此的话，用户在填写时才会写的比较详细。
最后，这个书面的报告还要经过多人的确认。有可能用户提出来的需求是其个人的建议，但是这个建议是否会得到其他人(如其直接领导)的认同呢?这个认同也非常的重要。因为一个需求可能会同时影响到多人(如多个人使用同一个作业)。在这种情况下，一个人提出的需求就可能会存在“自私”的情况。如会无意中撇开自己的责任等等。为此这些书面的需求，最终还需要在项目管理会议上进行讨论。让各个相关人员一起分析这个需求的合理性。
经过这几个环节之后，收集起来的需求一般就会比较立足于现实，同时又能够反映出企业未来一段时间内的需求。总而言之，就可以避免企业走极端路线。