以下文章来源于供应链道场 ，作者谌天宇
来源：供应链道场|作者：谌天宇
本文经授权转载
一
什么是需求分析？
福特公司的创始人亨利.福特问用户: 你需要什么样的交通工具?
大家的回答都是:我想要一匹更快的马?
福特先生最终给大家提供的是汽车。
那么福特先生有没满足大家的需求呢?
我们来分析一下福特先生的故事:
原始需求: 更快的马->为什么需要更快的马->跑得更快->为什么要跑得更快->节省时间,更快的达到目的地->更快的交通工具(背后的隐含的想法和目的) 。
从最初的说法到真正的想法和目的挖掘过程就是需求分析。
乔布斯创造了智能手机这个市场，可不是消费者直接告诉他的；也从来没有人告诉腾讯我们需要一个微信，没有客户告诉余承东他们需要一款挂在电线杆上的微型基站。
当你能挖掘到客户的真正需求时，我们才有机会设计制造出一款真正有价值的产品。同样每一个APS项目的成功，首先需要把握好需求分析。
二
何时去做需求分析？
在IT行业标准的方法论里面,一般是先进行调研,收集需求完成后再进行需求分析。但收集需求和需求分析是没有明显的界限区分的,收集需求时就需要去探究背后的目的,从某种程度上说,在收集需求的同时其实已经在做需求分析的工作。
三
如何识别客户的真实需求？
不仅要听客户说什么,还要看客户怎么做。
合格的顾问要能把需求用用户的故事句式讲清楚:什么样的业务场景,做什么事情,获得什么期望的收益;并通过客户的实际行为去验证，去客户生产现场看。理解客户的业务，这是必要的条件。
2. 以终为始的思维
我们小时候学习的故事:司马光砸缸 就是典型的案例。常人想着救人离开水,实际上呢也可以是水离开人，因此砸缸就是一个最优解了。
合格的顾问需要去理解深层次的需求、理解客户真正的目的是什么？ 将 需求的诞生过程来作为思考路径来思考。
3. 多问几个为什么
作为首尝APS的客户方，经常会无法准确描述需求;也有很多顾问由于缺乏业务能力和/或逻辑思维能力和或倾听的耐心，无法正确地理解客户的需求；也有可能客户一直在谈他认为的解决方案，而不是描述他的需求，这些现象都会让我们难于去找到真正的需求，对此我都会问客户几个问题:
你所描述的是不是这样的问题/业务场景? 这个问题/业务场景出现的频次怎么样? 从业务的影响角度来看，你为什么提出这个需求？解决这个问题能给你带来什么帮助?
四
需求分析阶段常犯的错误
把需求分析的过程过于简化，甚至完全简化到记录。
有的顾问，摆出一副认真的样子，对客户说：您说吧有什么需求？毫无引导、毫无讨论、毫无分析；拿了记录，不求甚解，只从IT技术角度或者本身软件的能力限制来筛选“这个可以实现，那个实现不了”，看似态度谦卑，实质是推卸责任，然后项目实施效果可想而知了。所谓顾问其实是“IT技术员、文员”，拉低了顾问这个高大上的名字。
我们在投标时的人力投入计划中，我们的需求分析阶段人力预算经常比友商多几倍，有的客户很高兴，有的客户很不理解。
2. 只想COPY现状，刻舟求剑
事实上已经存在的不见得就是合理的,即使客户这样做已经好多年了，甚至可能在行业里是领先的。APS的引入，就好比湘军开始购买西方的火器了，北洋水师买来了巨舰大炮了，还是运用原来的战法，能行吗？
每一次IT项目的导入，业务变革是前提，顾问了解APS的强大功能，完全有责任引导客户更往前看，去改变不合理的业务流程和计划业务规则（在计划领域的逻辑和参数）。这样的话，才有可能不仅仅提升了计划的过程效率，而且去提升客户整个的运营水平。
3. 需求分析输出的结果过于细节和繁琐
我们需要一个细致的需求调研分析过程，但不是需要一个繁琐的需求。过度专注于细枝末节,也会让项目“过犹不及”。
顾问要时刻清晰地认识到：管理是有成本的。一个小小的业务规则落实到APS系统，背后就是大量的对应数据需要维护。因此需要双方一起进行权衡决断、去芜存菁.对于效益提升不大的,但付出成本（实施过程的成本、日后数据维护的成本等等）很高的需求,优先级可以放低直至放弃，这个过程，顾问的引导作用是无可替代的，当然对顾问的要求很高。
4. 经验主义，生搬硬套
过早抛出顾问自己的解决方案，以此来影响客户对需求的表达；把顾问自己经历过的案例的一些做法，当作圣旨宝典，生搬硬套。殊不知，即使是产品和工艺一模一样的两个工厂，由于精益水平不同、数据现状不同、运作水平不同、管理诉求不同、未来规划不同等等原因，它们的需求也可能存在很大的不一致。
无论PMP指导手册还是无数的失败案例告诉我们，项目最怕的就是在实施过程中经常发生变更或者大幅度变更。那么造成变更的原因到底是甲方爸爸太随意了？还是顾问老师一开始曲解了客户需求？这里提醒顾问们，首先从自己身上找原因，从项目起始阶段找原因，扪心自问：我做好了需求分析这个关键工作了吗？
转自公众号：CIO俱乐部