“钻进去”和“跳出来”——信息系统的需求如何掌控？

难以把握的需求

企业的信息化是一个复杂的系统工程，涉及到管理的方方面面，比如战略管理、流程控制、人员管理、绩效考核等等；涉及到内部的各个部门，比如生产制造部、市场营销部、计划运营部、储运部等等；涉及到人员的各个层次，比如IT工程师、一线操作员、中层经理、高层领导。
信息化同时也是一个重要的工程，建设得好，可以有效的提升运营效率，降低管理成本，加强内部管控，提高核心竞争力；建设得不好，则有可能引发管理上的混乱，人心的浮动，生产的下降，市场的萎缩，削弱企业原有的竞争优势。

正因如此，决心实施信息化的企业大多严阵以待，不惜花费重金购买先进的软件和专业的服务，不过，结果却并不能尽如人意。众多被搁置的系统和失败的案例说明，信息化并不是那么容易的事情。

为什么信息化建设对企业来说如临大敌呢？关键在于对需求的把握不够准确和彻底，含混的需求和频繁的变动正是造成许多失败案例的罪魁祸首。

“跳出来”和“钻进去”

需求是信息化的基础，离开需求谈系统，必然如无源之水无本之木，无从谈起。企业在规划信息化建设时，必须清楚自己的根本需求是什么，是想提高效率，还是优化流程，或是加强管理；在具体的系统选型和调研时，必须关注具体的业务现状和改进需求，还要注意发现隐藏在表象之下的潜在需求，只有全面了解各方的真实需求，才能确保系统实施之后可以满足企业的需要。

简单点说，就是在整体规划时要“跳出来”，把握最根本的目的和动机，了解细节背后的真实想法，从局限思维中“跳”出来，站在企业的高度去设计和规划整个企业的信息化蓝图。即使对某一个应用系统来说，“跳出来”的能力也至关重要，透过用户琐碎细致的要求和描述，把握其真正想要达到的目标，可以避免细节上的过分纠缠，促进整个系统的推进和实施。

再说“钻进去”，信息化的大方向确定之后，随之而来的就是具体的应用系统建设，需要细致深入的了解和掌握用户的实际需求，不放过任何一个可疑点，练就孙悟空一样的火眼金睛，从用户寥寥数据的描述中，抓住他可能已经习以为常但是对于系统却至关重要的隐含需求。把所有可能的潜在需求点挖掘出来，等于是为系统的实施和上线扫清了障碍，为系统的稳定运行打好了基础。

锲而不舍的“钻”

道理不说不明，我们用具体的案例来加深理解。

某天下午，销售部的小王和信息部的小张在某间会议室里正在讨论调研中的商务系统需求。

小王：“订购申请的界面格式就是这个表格的样式，我希望各分公司的下单员进入系统后，系统能自动识别他们的分公司和可选的产品，然后通过指定一级大类、二级小类来选择产品编码，填写本次的下单数量。”

小张：“嗯，系统可以根据用户ID识别登录者的身份。”

小王：“我还想让系统自动生成单价，可以吗？”

小张：“单价是根据什么条件确定的，是产品编码吗？”

小王：“是的，我想能自己来维护，不同的编码会有不同的促销价格。”

小张：“应该是可以维护的。”

小王：“那太好啦，还有总价，系统也能自动算出来不？就用单价*数量，数量么，就用订购数量计算好了。”

小张（有点奇怪）：“订购数量？难道还有别的数量？不是只有一个本次的下单数量吗。”

小王（愣了一下）：“哎？还有我们返给分公司的赠送数量啊，不同时段的赠送品种和数量都不一样的，这个最好也能让我来维护。”

小张（叹气）：“好吧，也就是说，分公司最后拿到的产品数量是他付钱订购的数量，也就是本次的下单数量，再加上我们赠送的数量，对吧？”

小王（点头）：“对。”

小张：“那么这个赠送的数量根据什么来算呢？是产品编码？还是下单数量？”

小王：“嗯，每个产品编码根据不同的下单数量，返的数量也不同。”

小张（揉揉额角）：“能举个例子吗？”

小王：“比如分公司订100个A产品，我们返他10%，订1000个，返180个。”

小张：“就是按订购范围来返呗。”

小王（犹豫）：“也不全是，有时候，小于100的返10%，等于100的返15个，是按阶梯来的。”

小张（考虑了一会）：“嗯，总之就是由你们维护一个数量范围，呃，就是阶梯，然后针对每个阶梯给出返给分公司的数量或者百分比，对吧？”

小王（点头）：“对的对的，返赠数量按阶梯走，单价也是。”

小张（汗）：“还有单价？每个产品编码的单价不是固定的吗？”

小王：“是固定的，不同阶梯的价格是固定的。”

小张（无奈）：“那就是说，单价和返赠数量一样，都是按阶梯确定，比如1-100个是1块钱，100个是8毛钱，101-200个是7毛钱，是不是这样的？”

小王（点头，感动）：“是的是的，就是这个意思！”

业务人员对自己的流程如同对掌心的纹路般熟悉，在叙述需求的时候难免会省略掉许多他们认为理所应当的前提和条件，而这些条件对信息系统来说决不是可有可无的，必须准确的加以说明才能保证流程的正确和顺畅。

比如案例中的小王，能看得出他对这个流程已经十分熟悉，所以，按照订购数量确定单价和返赠数量这样的规定，对他来说就像吃饭呼吸一样自然，所以才会在小张询问还有别的数量的时候愣住。在小王看来，这些本来就是不说自明的，即使他不说，大家也都知道的啊。

但是对于小张来说则不然，如果没有特殊说明，他不会想到还有返赠数量的存在，更不会想到单价还要与订购数量挂钩，自然系统里也不会有。如果不是小张敏锐的察觉到小王的弦外之音，这个隐含的需求点很可能就悄悄的潜伏起来了，也许等到系统上线后才会被发现。到了那时候，大家再怎么后悔恐怕也为时已晚，系统已经开发完毕了，再想改动可就不是那么简单的事情了。

所以，无论进行调研的系统其规模大小如何、重要程度如何、使用部门如何，在软件选型或者系统开发之前，都应该进行细致全面的需求调研，尽量发现业务操作中隐含的、关键的、容易被忽略的需求点，无论用户是否把它当作重点。

很多时候，用户所关心的问题也许并不是系统实现时的难点，反而是那些长期积淀下来的、对业务起着关键作用的、有着高度的灵活性、复杂性和多样性的启发式规则，因为比较接近于人脑的思考模式，所以偏重逻辑运算的计算机系统并不擅长处理这些“潜规则”，因而实现起来会比较吃力。

总揽全局的“跳”

还是在同一间会议室，小王正在给小张解释销售部针对分公司提交上来的订购申请的审核流程。

小王：“订购申请的审核界面，我希望能把所有待审核的都列出来，然后我们选择通过或者驳回。。。”

小张：“等一下，我看你提供的表格里，把订单里的所有产品都列出来了？”

小王：“这样我看得清楚些。”

小张：“好吧。那么，你在审核的时候，通常是一个一个的过，还是几个产品一起过？”

小王：“嗯，一个一个的过。”

小张（点头）：“好，你继续。”

小王：“通过的产品，就转到分配库位的步骤，如果是驳回的，就让分公司重新修改，但是废除的订单就不能再改了。”

小张：“除了通过和驳回，还有废除？”

小王点头。

小张：“废除和驳回的订单，有什么区别？”

小王：“废除的不能再修改，但是可以查询到。驳回的可疑修改后重新提交。”

小张：“还有一个问题，如果订单包含多个产品，你们怎么驳回？”

小王（有点迟疑）：“就是，把产品驳回去呀。。。”

小张：“单个产品驳回吗？”

小王（仔细想了想）：“是。”

小张：“那么你考虑一下，如果某张订单有两个产品，你通过一个，驳回一个，那么这个订单的状态是算‘通过’还是算‘驳回’？是该由分公司修改还是该进入下一个审批环节？修改的时候已经通过的产品还让不让分公司改？”

小王皱眉。

小张：“还有，如果被驳回的产品分公司修改了，是要重新经过你的审核呢，还是跟那个通过的产品一起进入下一步审批？”

小王（擦汗）：“这些我还真没仔细想过。。。”

小张：“这个问题你必须想清楚，不然单据没办法管理了。”

小王点头。

小张：“从系统的角度来说，包含多个产品的单据审核，只要有一个产品没通过就把整单都驳回去，等修改后重新提交，再进行整单的通过和驳回。当然，需要对产品进行单独管理的情况除外，你们的订购申请有这方面的管理要求吗？”

小王摇头：“没有，我们出库的时候都是按订单发货，没有拆开来出库的。”

小张点点头：“那我还是建议对整张订单进行通过、驳回和废除，既方便订单的控制也便于实际操作。”

小王（点头）：“还是你们专业啊，那就按整单走吧！”

具体的业务人员对本职工作的熟悉程度毋庸置疑，但这种熟悉也从某种程度上限制了他们的思维模式，使他们局限于自己的视角看问题，无法对流程的整体进行思考。但是，应用系统并不仅仅是为了减轻某个人、某个部门的工作强度而设计的，不可能只满足部分人的需要，必须从整个流程的角度去衡量，从企业利益的目标去设计，因此必须跳出个人和部门的局限，系统的规划信息化建设的方案。

比如案例中的小王，他最熟悉的不外乎是每天都在做的事情，因此他对系统提出的要求也是以自己的工作习惯为依据的。但是由于过于拘泥于细节，小王并没有对审核背后的目的和要求多做考量，他了解的只是自己的日常工作，对单据流转的流程整体和目的了解不多。所以，当小张问他如果按单个产品驳回后出现的各种情形该如何处理时，小王冒汗了。

小张根据以往的系统设计经验，从小王的简略叙述中发现了销售部审核流程在设计上的模糊，并据此设想了可能导致的混乱状况，请小王仔细考虑。然后针对订单审核的流程提出了自己的建议，避免了按产品审核导致的系统设计和业务管理上的麻烦，尤其是这些麻烦根本没有必要。

所以，无论是做单个系统的选型和调研，还是做信息化建设的规划和设计，除了深入的了解需求以外，在恰当的时候跳出具体的系统、部门和个人视角上的局限，对信息化的建设者来说，也是不可缺少的能力之一。

如果作为应用系统的建设者和规划者，缺乏系统思考的眼光和掌控需求的能力，对于企业的信息化建设，无疑是一个重大的缺憾和风险，因为，完全按照业务部门的需求建立起来的系统，所能起到的只能是提高效率的作用，对于流程整合和提高竞争力来说毫无益处，而且随着类似系统数量的增加，信息无法共享，部门缺乏协作，可能最后连基本的提高效率的作用都发挥不出来，反而成为限制企业发展的绊脚绳和随时可能触发的陷马坑。

事半功倍的小技巧

道理讲清楚了，该谈具体怎么做了。

需求调研是信息系统建设的第一步，也是最关键和最基础的一步，这项工作完成的质量将直接影响应用系统最后的使用效果。因此，进行需求调研的一般都是相对比较有经验的需求分析师或者项目经理，他们的技巧和经验对如果做好需求调研有很高的参考价值。

下面是几个有关需求调研的几个小技巧，也算是经验之谈。

1.       确保你们说的是同一件事。

由于调研人员和业务人员在专业分工上的差异，双方各有各习惯的表达方式和专业术语，这种差异很容易导致沟通上的障碍。为了减少类似的误会发生，最好用实物来说明问题，比如，在讨论问题之前，先确认一下马上要讨论的是否就是你手中的表格，或者把业务部门的流程图打印出来，按图索骥。

2.       用“业务语言”交谈。

前面已经说了，调研人员和业务人员各有各的语言，沟通上可能存在困难。相对来说，业务人员对IT术语的理解程度更差一些，而调研人员应该尽可能多的了解业务才能准确理解需求，所以建议调研人员能用“业务语言”来交谈。这样既可以减少双方语言上的沟通障碍，也可以促进调研人员迅速理解和掌握业务需求。

3.       掌握倾听的技巧。

需求调研过程中说得更多的是业务人员，而调研人员更主要的任务则是倾听，从需求描述中发现问题，提出来并进一步确认，因此，倾听的技巧对于调研人员来说更为重要。在倾听的时候，尽可能多的获取信息，发现叙述中隐含的潜在需求和规则；在复述的时候，尽可能客观的描述问题，不夹杂个人的偏好和评价；在有疑问的时候，尽可能简单的提出疑点，对模糊不清之处再三确认。这样的倾听过程，可以让业务人员充分的表达需求，避免由于叙述上的疏漏和误解导致系统的缺陷。
 
4.       举例说明。

遇到比较复杂和难以理解的情况，最好用具体的例子和数据来进一步说明。不仅要让业务人员举例说明，也要把自己对问题的理解通过举例来说明，避免由于问题复杂而导致的理解偏差。
 
5.       尊重业务人员的意见，提出专业的建议。

对于某个具体的流程来说，业务人员是最有发言权的，他们有很多在工作中积累的经验可供借鉴，对此调研人员应给予充分的重视和尊重，不能因为见解不全面不正确而嗤之以鼻，横加指责。当然，对于业务人员考虑不周的需求，调研人员可以根据自己的经验和理解提出建议，帮助业务人员分析和寻找更为合适的解决方法。

总之，企业的信息化建设离不开准确而全面的需求调研，要想做好调研，必须既要能“钻进去”，又要能“跳出来”，这两者是互为补充相辅相成的，只有了解全面的业务需求，把握整体的建设方向，才能保证企业的信息化建设取得预期的效果，为企业带来稳定的发展。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友