错误的需求分析对任何CIO来讲都是一场噩梦。在需求分析阶段看似微不足道的疏忽，都有可能成为项目失败的罪魁祸首。无论CIO的项目管理经验多么丰富，基于错误需求分析的IT项目，其结果只能以失败而告终。但是，即便如此，IT项目前期的需求分析仍然没有引起CIO们的普遍重视。他们往往更多地关注项目的时间、成本、质量、组织、范围和客户满意度，却没有意识到，需求分析是所有项目成功要素发挥作用的前提，如果需求分析有误或者不到位，任何IT项目管理技巧和对IT项目的任何控制，都是没有价值的。

　　与此同时，对于缺乏经验的CIO来讲，需求分析恰恰又是整个项目中最容易让人焦头烂额的阶段——业务部门提出的需求往往文不对题并且不断变化，甚至在项目接近尾声的时候，业务部门仍然在不断地提出新需求。挖掘业务部门的项目需求时，CIO往往感觉力不从心，业务部门对项目需求的反复无常，又让CIO措手不及。那么CIO该如何确保项目需求分析的正确与充分，面对业务部门反复无常的项目需求又该如何应对呢?为此，记者NSIGHT近日请到了武汉健民集团信息中心主任柳骏、浙江吉利控股集团信息系统部副经理章正柱、AMT咨询深圳公司总经理杨春波，围绕“需求分析”相关话题展开了讨论。

　　记者：我们经常会听到一些CIO抱怨说，对业务部门提出的需求IT人员看不懂，甚至根本不能称之为“需求”，为什么会出现这种情况?

　　章正柱：我就遇到过这种情况。业务部门对IT不太了解，他们有时候会把IT想象得过于神化，觉得系统上了之后就会无所不能，往往提出一些脱离实际的需求。

　　我印象比较深的是我们集团的“一车一档”系统，这是做ERP的时候业务部门提出的需求，他们希望在ERP中实现这样的功能。一车一档系统管理的内容比较多，从汽车生产的订单接收，到生产的组织，再到最后的销售结果反馈等环节都有涉及。对于业务部门提出的这个需求本身，我觉得是合理的，但是如果要做“一车一档”系统，必须要有采购系统、生产系统、物流系统和销售系统做支撑，在没有销售系统的情况下，单纯依靠ERP去实现“一车一档”系统就显得不切实际了。

　　柳骏：对于任何IT项目的需求分析，如果主要依靠业务部门去提是绝对不行的，因为他们对系统功能的认知非常有限，很难在项目前期提出有效的需求。实际上，很多项目在需求分析阶段，业务部门压根就提不出什么具体的需求，倒是在系统上线之后，他们的需求才能慢慢地涌现，最后甚至铺天盖地地呈现。我在很早以前就遇到过这种情况，前期做需求分析的时候，业务部门会说：“我们没什么需求，你们IT部门根据自己的想法去做，做出来我们能用就行了。”结果系统做出来了以后，业务部门的需求才真正爆发出来，搞得项目组焦头烂额。杨春波：前面两位IT主管都提到了业务人员对IT的不了解，我觉得还有一个很重要的原因，就是“语言不通”。在企业信息化程度不高的情况下，业务人员的系统使用经验较少，他们提出的需求往往用的是业务语言，比如说：“我需要的是在录入这两项数据之后，分摊成本能在这个窗口直接蹦出来??”而我们IT人员熟悉的是系统语言，比如：“能以这个字段为关键字，按照结算时间顺序排列，显示出一个报表。”

　　从业务语言到系统语言需要一个翻译的过程。如果IT人员到公司时间不长或者是对业务不熟的话，难度确实是不小。不过CIO们别上火、别抱怨，他们应该注意多培养IT人员的业务知识，鼓励IT人员经常与业务部门多交流。很早就有人提出，财务人员要“走出账房”，我觉得IT人员也应该时不常地“远离电脑”。

　　记者:柳骏刚刚提到了在需求分析阶段仅仅依靠业务部门提需求是不够的，那么你们认为获取IT需求的途径应该有哪些?

　　柳骏：需求分析不能完全依赖业务部门，在这个阶段，IT人员不仅要充分介入进去，还要钻到业务中，与业务部门绑在一起，和业务人员成为朋友，尽量成为业务方面的专家。

　　具体来讲，IT人员可以先通过访谈的方式，了解业务流程的大概状况，然后再深入到业务部门，跟着业务人员，把业务流程整个走一遍，以充分熟悉业务流程的每一个环节。我觉得需求分析有点类似于机械行业的工艺卡片，工艺卡片是以工序为单位，详细地说明整个工艺过程的一种工艺文件，用来指导工人生产，帮助车间管理人员和技术人员掌握整个零件加工的过程。做需求分析也要像编制工艺卡片一样，细化到业务流程中的每一个动作，这是非常有必要的。因为只有对业务流程的每一个细节都足够了解了，才有可能在此基础上进行流程优化、重组，尽可能多地挖掘出业务部门对系统的潜在需求，进而形成项目需求分析报告。

　　除了分析业务部门的工作流之外，还要收集他们日常工作中用到的各种单据、报表和表单等，也就是通常所说的票据流。实际上，票据流是业务部门工作流的载体，通过这些载体，不仅可以对工作流有更加深入的理解，还可<