大多数的IT项目估计都不可能得到如本案例一样的实质支持，一把手主动提出要CRM，但最终的结果仍然让人不满意，那么其他项目的结果更加可想而知。到底哪里出了问题呢？通过本案例，我们可以得到什么经验和教训呢？

　　1：一定要搞清楚真正的需求，即需求背后的需求（英文针对前一个需求用wants，即客户嘴里说出来的需求;针对后一个需求用needs，即客户心里真正想要的，甚至他自己还不清楚地知道。可惜，客户自己有时候对needs并不清晰，朦朦胧胧地有这种感觉，说出来就变成了wants;或者有些客户“爱思考”，他们会想我要的needs如何实现，要得到这个结果，我需要做1、2、3等几步，然后把123说了出来，成为他们的需求，却没有多说一句，把做123最终要达到的目的告诉你，我通常称这种行为为客户的需求翻译。而且可能由于认知的局限性，在需求翻译的过程中翻成了错误的123。总之，这两种情况都增加了你对客户真正needs把握的难度）。如何做到真正把握客户Needs呢？多问几个为什么，层层追问下去，直到发掘出其最本源的管理目的（针对企业应用而说）。本案例中经过层层追问，我们可以知道老大要做CRM的最终目的是竞争加剧的环境下获得更多的收入，方法有两个：（A）增加客户数量;（B）增加本公司在每个客户钱包中的百分比（share of wallet）。（A）需要增加更多的销售线索或项目盈率，所有要全员皆Sales;（B）要增加客户心中对A公司苦劳感知的占比，所以需要统计所有的服务记录。从更多的销售线索到从上到下全面的客户关系图这个说出来的需求wants就是一种有偏差的需求翻译。

　　2：搞清楚了真正的需求needs，也就了解了需求的价值。接下来要将needs层层分解成其实现的步骤wants，分解是否正确是一个关键问题，检验标准就是判断needs的价值是否可以实现。以本案例为例，从上到下全面的客户关系图能确保得到更多的销售线索吗？如果CIO本身有这种业务经验或知识，马上提出这种顾虑，相信一定会得到老大的肯定。如果CIO不清楚，可以去问销售副总裁或提出需求的老大（一个非常好的机会和业务沟通，取得一致理解和获得支持），也可以去Internet上查别人上CRM碰到的问题，相信销售不愿意贡献出来全部的销售线索和详细的客户信息是一个普遍的困扰。

　　3：如果最终对于需求或价值的把握还是朦朦胧胧的，其实对于该IT项目就应该放弃或者暂时搁置，等待以后需求和价值的明晰。如果不愿意放弃对其价值的追求，业务和IT都愿意赌一把，这时候科学地办法就是类似任何业务新产品的研发，做POC或原型去验证需求、验证价值。做POC或原型有两个关键，（1）是控制投入，尽可能用少的钱，尽可能聚焦在价值可能大的需求上;（2）迭代要快，最快地见到结果，完成验证，无论对错。软件开发中的Scrum方法的指导思想同样可以用于POC过程，一要快，最快时间见到结果去体验、去验证;二在每个spring迭代中怎么确定要实现的功能，价值大小就是一个主要依据。POC的过程应该发生在立项前，当然更是在和乙方签合同前。本案例中用Sharepoint service做一个POC系统，或者买2~3个用户的SaaS CRM应用来验证都是一种很好的对策，这也是CIO或IT部门价值最保守的体现，是其价值体现的自留地，因为这其中需要的专业知识正是CIO或IT部门的强项。

　　4：80/20原则同样适用于IT系统的建设，即80%的价值来源于20%的需求或功能，所以无论是在POC过程，还是POC成功后全系统的需求调研，都应该聚焦，其他需求无论是重要性还是紧迫性都应该居于次席。平均用力的结果增加了成本，也稀释了价值，影响了ROI，还降低了敏捷性，业务部门可以使用的系统上线的时间拖的越长，带来的需求变化的风险就越大。本案例中研究报告邮件的发送和确认做的很复杂，其实必要性不大，更大的可能性是相关部门想体现自己位子的重要性或保住自己的位子。

　　5：将4扩展一下，哪些需求属于聚焦的20%？其判断依据是价值大小，当然更科学的做法还有综合考虑重要性、紧迫性、成本、风险、难度等。当将每一个需求都从这些维度一一分析的时候，业务和IT都会首先选择价值大、风险小、成本小的需求，至于第二梯队的需求，就取决于各方的沟通、妥协和权衡。所以，价值等维度是一把尺子，时刻用来衡量需求在本IT项目中的取舍。按照这个原则，本案例中每年的研讨会安排、相关杂志的发放、研究报告邮件的发送和确认、研究员的工作时间统计等需求完全可以不做，或最简单地实现。

　　6：买钻头的目的其实是要墙上的洞。如果要的是大洞，买的是小钻头，还可以多钻几次，拼凑出一个大洞，但无疑要多花时间和力气;如果要的是小洞，买的是大钻头，这时要么干瞪眼，要么钻好的大洞再把不需要的地方堵上，也要多花力气和钱。最合适的是按照洞的大小买合适的钻头，很基本的常识。可是在IT项目上，这样的常识却经常被违背。对于一个IT管理系统，CXO或VP级别用的最多的其实是报表，尤其是分析型报表（技术上可能用通常的报表或BI技术实现）。可是大家经常会看到一期ERP、二期BI;一期BOSS，二期经分，理由是先要有数据，才能分析。似乎很有道理，可由此推导出实现的顺序应该是先数据，后分析就大错特错。因为CXO或VP等老大的需求才是最终的目的，所以需求设计的顺序应该是先分析，后数据，以终为始。当然，调研需求的时候，CXO或VP这一级一定不能漏掉，而且应该放到最前面，最重要的一环。本案例中搞清楚了老大为什么要CRM这个“终”，再碰到业务提出的邮件发送确认、研究员时间管理等需求的“始”，就可以很快判断出是否匹配。

　　7：国内IT项目需求调研时，常见的对象是基层骨干，因为他们是最容易调动来配合调研，且对实际操作流程熟悉的人员;中层经理也能够占用他们一些时间，主要是了解其报表需求。CXO或VP层通常只会在项目启动会上发表一番重视项目，设定一个要建成XXX范围最XX的XX系统的最高指示，未来可能偶尔出来听一下项目组进度报告、调配一下资源和矛盾。当然，基层和中层也会将他们过往领悟的高一层的需求说出来，但是否准确，是否是经过多层次翻译，是否是盲人摸象就不得而知了。基层最关心的是什么呢？使用最简便，最轻松，不要找麻烦让我加班，但一定要突出岗位的重要性，不能让我被取代。本案例中研究报告邮件的发送和确认非常复杂：邮件发送成功了吗？不成功是什么原因？是对方邮箱满了还是其他什么原因？不成功能否隔段时间再重发？重发要尝试几次？邮件客户打开看了吗？零零总总一系列的需求就是在服务好客户，提高满意度这个高层指示下，基层积极表现，同时体现本岗位重要性的需求。中层最关心的是什么呢？部门权利、部门价值、部门管理。本案例中有一个需求是研究员的工作时间管理。为什么要这个需求呢？因为对A公司的客户来说，最有价值的是分析报告的含金量，所以提升报告的含金量是老大的最高指示。可是提高含金量更多的是一种创造性的工作，没有什么好招来改善或者短期内见不到效果，而面对老大的要求能什么都不做吗？当然不可以，所以相关中层自然想到的解决方法是管理研究员的时间和工作内容，寄希望用时间的堆砌（更花功夫和心思）来提高报告的含金量，于是，经过了3层翻译的需求“研究员的工作时间管理”诞生了。我们知道真正的需求needs其实都是管理的目的，应该都是从公司战略分解下来的，而实际的需求调研对象集中在基层和中层，他们的需求并不天然就和公司战略吻合，甚至公司的战略都不是其最优先考虑的点。这一点需要CXO和VP级集体的介入和努力，从全局去考虑问题，优化调配，妥协权衡。所以，需求一定要和CXO和VP级沟通，和公司的战略紧密关联。

　　8：本案例中，随着需求调研的进行，CIO觉得需求越来越多，“成为了一个大拼盘”，跟销售、客户服务相关的东西都往里装。由于项目是一把手提出的，大家都要积极表现，从各种渠道了解的CRM概念、场景、需求都想实现，再加上7分析的中层和基层的心理活动，CIO如何从这些需求中筛选出最重要，价值最大的20%呢？3介绍了基于价值大小的准则，这里进一步将其限制到A公司这个特定的企业。A公司老大在见到了不菲的预算以及一年多的项目周期后，为什么仍然最后同意了CRM项目的立项呢？除了是其主动提出这个原因外，从厂商、方案供应商、管理咨询公司、MBA教育、各种管理杂志、其他CRM成功案例等等渠道了解的CRM系统价值影响了其判断，似乎自己企业也可以享受这些价值，却没有将这些潜在价值具体实例化到自己这个企业、特定流程、特定管理模式、特定当前状态，只有实例化后才可以去检验这些价值是否实实在在，是否可以得到。

　　9：项目进行过程中，需求不断增加是一个我们面临的一个普遍现象。甲方通常认为理所当然，因为合同已经签订，合同金额的上限已经确定，需求多更占便宜。可是他们没有站在乙方的立场上去想问题。任何一个有经验的乙方，合同签订的时刻，就已经确定了合理利润率下能够提供服务的最大人天数，所以他们在需求调研阶段的一个重要任务是“控制客户需求的发散性思维”，在能承受的范围内接受客户的需求，在不能承受的时候要求客户取舍，或放入二期。可是，取舍的标准是什么呢？是按照针对客户价值的大小来取舍，还是自己的难易程度、实现的人天数量来取舍呢？即使在能承受的范围内，是花更多的人天来把价值最大的20%实现更好，还是平均分配到所有的需求上呢？显然，CIO也要在这些方面干预，以获得最大的价值。