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