要想做好企业信息化建设的需求调研，必须既要能“钻进去”，又要能“跳出来”。
　　需求是信息化的基础，企业在规划信息化建设时，必须清楚自己的根本需求是什么，是想提高效率，还是优化流程，或是加强管理；在进行具体的系统选型和调研时，必须关注具体的业务现状和改进需求，还要注意发现隐藏在表象之下的潜在需求，只有全面了解各方的真实需求，才能确保系统实施之后可以满足企业的需要。
　　简单点说，就是在整体规划时要“跳出来”，把握最根本的目的和动机，了解细节背后的真实想法，从局限思维中“跳”出来，站在企业的高度去设计和规划整个企业的信息化蓝图。
　　再说“钻进去”，信息化的大方向确定之后，随之而来的就是具体的应用系统建设，需要细致深入的了解和掌握用户的实际需求，把所有可能的潜在需求点挖掘出来，等于是为系统的实施和上线扫清了障碍，为系统的稳定运行打好了基础。
　　锲而不舍的“钻”
　　某天下午，销售部的小王和信息部的小张在会议室里正在讨论调研中的商务系统需求。
　　小王：“这是订购申请的界面格式，我希望各分公司的下单员进入系统后，系统能自动识别他们的分公司和可选的产品，然后通过指定一级大类、二级小类来选择产品编码，填写本次的下单数量。我还想让系统自动生成单价，可以吗？”
　　小张：“单价是根据什么条件确定的，是产品编码吗？”
　　小王：“是的，我想能自己来维护，不同的编码会有不同的促销价格。如果系统也能自动算出总价，就用单价×数量，数量就用订购数量计算好了。”
　　小张（有点奇怪）：“订购数量？难道还有别的数量？不是只有一个本次的下单数量吗？”
　　小王（愣了一下）：“哎？还有我们返给分公司的赠送数量啊，不同时段的赠送品种和数量都不一样的，这个最好也能让我来维护。”
　　小张（叹气）：“好吧，也就是说，分公司最后拿到的产品数量是他付钱订购的数量，也就是本次的下单数量，再加上我们赠送的数量，对吧？那这个赠送的数量根据什么来算呢？是产品编码？还是下单数量？”
　　小王：“嗯，每个产品编码根据不同的下单数量，返的数量也不同。比如分公司订100个A产品，我们返他10%，订1000个，返180个。但也不全是按订购范围来返，有时候小于100的返10%，等于100的返15个，是按阶梯来的。”
　　小张（考虑了一会）：“总之就是由你们维护一个数量范围，也就是阶梯，然后针对每个阶梯给出返给分公司的数量或者百分比，对吧？”
　　小王（点头）：“对的对的，返赠数量按阶梯走，单价也是。”
　　小张（冒汗）：“还有单价？每个产品编码的单价不是固定的吗？”
　　小王：“是固定的，不同阶梯的价格是固定的。”
　　小张（无奈）：“那就是说，单价和返赠数量一样，都是按阶梯确定，比如1～100个是1块钱，100个是8毛钱，101～200个是7毛钱，是不是这样的？”
　　小王（使劲点头）：“就是这个意思！”
　　能看得出小王对这个流程已经十分熟悉，所以，按照订购数量确定单价和返赠数量的规定，对他来说就像吃饭呼吸一样不言自明。但是对于小张则不然，如果没有特殊说明，他不会想到还有返赠数量，更不会想到单价还要与订购数量挂钩。如果不是小张敏锐地察觉到小王的弦外之音，这个隐含的需求点很可能就悄悄地潜伏起来了，而等到系统上线后再发现，想改动就不是那么简单了。
　　所以，无论进行调研的系统其规模大小、重要程度和使用部门如何，在软件选型或者系统开发之前，都应该进行细致全面的需求调研，尽量发现业务操作中隐含的、关键的、容易被忽略的需求点，无论用户是否把它当作重点。
　　很多时候，用户所关心的问题也许并不是系统实现时的难点，反而是那些长期积淀下来对业务起着关键作用的、有着高度的灵活性、复杂性和多样性的启发式规则，因为比较接近人脑的思考模式，所以偏重逻辑运算的计算机系统并不擅长处理。
　　总揽全局的“跳”
　　还是在同一间会议室，小王正在给小张解释销售部针对分公司提交上来的订购申请的审核流程。
　　小王：“我希望订购申请的审核界面能把所有待审核的产品都列出来，让我们选择通过或者驳回……”
　　小张：“好吧。那么，你在审核的时候，通常是一个一个过，还是几个产品一起过？”
　　小王：“嗯，一个一个过，通过的产品就转到分配库位的步骤，如果是驳回的，就让分公司重新修改，但是废除的订单就不能再改了。”
　　小张：“除了通过和驳回，还有废除？那废除和驳回的订单有什么区别？”
　　小王：“废除的不能再修改，但是可以查询到。驳回的可以修改后重新提交。”
　　小张：“那如果订单包含多个产品，你们怎么驳回？”
　　小王（有点迟疑）：“就是，把单个产品驳回去……”
　　小张：“如果某张订单有两个产品，你通过一个，驳回一个，那订单的状态是算‘通过’还是算‘驳回’？是该由分公司修改还是进入下一个审批环节？修改的时候已经通过的产品还让不让分公司改？还有，如果分公司修改了被驳回的产品，是要重新经过你的审核，还是跟那个通过的产品一起进入下一步审批？”
　　小王（擦汗）：“这些我还真没仔细想过……”
　　小张：“从系统的角度来说，包含多个产品的单据审核，只要有一个产品没通过就把整单都驳回去，等修改后重新提交，再进行整单的通过和驳回。当然，需要对产品进行单独管理的情况除外，你们的订购申请有这方面的管理要求吗？”
　　小王摇头：“没有，我们出库的时候都是按订单发货，没有拆开来出库的。”
　　小张点点头：“那我还是建议对整张订单进行通过、驳回和废除，既方便订单的控制也便于实际操作。”
　　小王：“还是你们专业，那就按整单走吧！”
　　具体的业务人员对本职工作的熟悉程度毋庸置疑，但这种熟悉也从某种程度上限制了他们的思维模式，使他们局限于自己的视角看问题，无法对流程的整体进行思考。但是，应用系统并不仅仅是为了减轻某个人、某个部门的工作强度而设计的，不可能只满足部分人的需要，必须从整个流程的角度去衡量，因此必须跳出个人和部门的局限，系统地规划信息化建设的方案。
　　比如案例中的小王，他对系统提出的要求就是以自己的工作习惯为依据的。但是由于过于拘泥细节，并没有对审核背后的目的和要求多做考量，他了解的只是自己的日常工作，对单据流转的流程整体和目的了解不多。所以，当小张问他如果按单个产品驳回后出现的各种情形该如何处理时，小王冒汗了。
　　小张根据以往的系统设计经验，从小王的简略叙述中发现了销售部审核流程在设计上的模糊，并据此设想了可能导致的混乱状况，然后针对订单审核的流程提出了自己的建议，避免了按产品审核导致的系统设计和业务管理上的不必要的麻烦。
　　完全按照业务部门的需求建立起来的系统，只能提高效率，对流程整合和提高竞争力毫无益处，而且随着类似系统数量的增加，信息无法共享，部门缺乏协作，可能最后连基本的提高效率的作用都发挥不出来，反而成为限制企业发展的绊脚绳和随时可能触发的陷马坑。
　　所以，无论是单个系统的选型和调研，还是信息化建设的规划和设计，除了深入的了解需求以外，在恰当时候跳出具体的系统、部门和个人视角上的局限，对信息化的建设者来说，也是不可缺少的能力之一。
　　事半功倍的小技巧
　　确保你们说的是同一件事
　　由于调研人员和业务人员在专业分工上的差异，双方各有自己习惯的表达方式和专业术语，这种差异很容易导致沟通上的障碍。为了减少类似的误会发生，最好用实物来说明问题，比如，在讨论问题之前，先确认一下马上要讨论的是否就是你手中的表格，或者把业务部门的流程图打印出来，按图索骥。
　　用“业务语言”交谈
　　如前文所述，调研人员和业务人员沟通上可能存在困难。业务人员对IT术语的理解程度更弱一些，调研人员应该尽可能多地了解业务才能准确理解需求，所以建议调研人员能用“业务语言”来交谈。这样既可以减少双方语言上的沟通障碍，也可以促进调研人员迅速理解和掌握业务需求。
　　掌握倾听的技巧
　　需求调研过程中说得更多的是业务人员，而调研人员更主要的任务则是倾听，从需求描述中发现问题，提出来并进一步确认，因此，倾听的技巧对于调研人员来说更为重要。在倾听的时候，尽可能多地获取信息，发现叙述中隐含的潜在需求和规则；在复述的时候，尽可能客观地描述问题，不夹杂个人的偏好和评价；在有疑问的时候，尽可能简单地提出疑点，对模糊不清之处再三确认。这样的倾听过程，可以让业务人员充分表达需求，避免由于叙述上的疏漏和误解导致系统的缺陷。
　　举例说明
　　遇到比较复杂和难以理解的情况，最好用具体的例子和数据进一步说明。不仅要让业务人员举例说明，也要把自己对问题的理解通过举例来说明，避免由于问题复杂而导致的理解偏差。
　　尊重业务人员的意见
　　对于某个具体的流程来说，业务人员是最有发言权的，他们有很多在工作中积累的经验可供借鉴，对此调研人员应给予充分的重视和尊重，不能因为见解不全面、不正确而嗤之以鼻，横加指责。当然，对于业务人员考虑不周的需求，调研人员可以根据自己的经验和理解提出建议，帮助业务人员分析和寻找更为合适的解决方法。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。