"需求调研"惹起的祸端
最近蓝兰集团信息中心主任张成又遇到了一个新问题，公司刚刚启动了一个信息化新项目，就是内部供应链的项目，各个制造实体的订单管理将统一在一个操作平台上进行。
通过这个平台，董事长魏武期望集团统一接单，然后将订单分派给集团内部汽车配件制造实体-蓝兰气泵制造有限公司、蓝兰汽车橡胶制品制造有限公司、蓝兰汽车轴承制造有限公司等五个公司以及正在不断扩大的外部供应商。
"需求调研"惹起的祸端
这个战略意图我们不去讨论它。现在的问题是，为了稳妥起见，魏武要求，先拿生产当家产品的蓝兰气泵制造有限公司做试点，第一建造一个统一平台，第二将气泵的内部供应链做透，以方便客户、业务代表检查和监督订单执行的各个环节。
张成已经和南方管理软件公司确定了通过对南方管理软件ERP的E3(15.2)版本进行适应性改造，以适应内部供应链的要求。也就是在基础数据的管理上，以E3为基准，ERP的模块功能按照订单的执行过程进行整合，最后进行适当的二次开发。
按照计划，2006年8月上旬南方公司将派华东大区的咨询顾问来项目现场进行为期半个月的现场需求调研，这时问题出现了。
最早在签约的时候，张成曾经和软件公司讨论过，需求调研由顾问按照提纲进行访问，然后整理出文档供确认。现在对方的项目经理李封来邮件说，将由顾问到现场对业务部门的需求责任人(大部分是管理人员)进行"模块需求规格说明书"编写的培训，然后顾问用四天时间对大家提交的需求规格说明书进行批改。
最后将收集上来的资料带回华东大区，由乙方项目组进行集中梳理并与标准产品进行匹配，看差距在哪里，然后确定实施与开发任务。
"马蹄"焉能"牛蹄"补
张成对整个计划没有特别疑问，这个安排还是比较符合一般项目的做法，但有一点是需求说明全部由业务部门来写，效果能不能得到保证？张成见过南方公司提供的"模块需求规格说明书"，完全是需求分析师、系统设计师才能写出来的东西，有许多专业的表达方式，他自己对许多词语还搞不透。
蓝兰气泵制造有限公司的管理干部大部分是老员工，许多人勉强能打字，查查报表，现在要画流程图，说明字段输入输出规范、系统关联等这样的文章实在是勉为其难，一天的培训很难让大家有这样的转变，估计实际的调研进度将要大受影响。
他把这个顾虑告诉李封时，李封说，这其实也是为张成好，业务部门按照这个规范写出来的东西，他们确认后，可以直接给需求分析与程序开发人员使用，减少了中间环节，提高项目效率，也明确了责任，将来，他们有需求变更也有明确的依据。
张成琢磨，这样是不是算是"下套"？-你看，从最基层到项目组都承认了这个需求，蓝兰公司与南方公司的契约也就更清楚了，将来有什么问题，难道还找李封？
当然张成担心的主要还不是对方是不是"下套"，而是当前这样的表达方式是不是能真切地表达项目需求，会不会因为表达方式的原因使基层的管理需求无法呈现，或者出现类似"精确的错误"这样的东西。
为此他向李封严正提出，由双方项目组人员联合成立模块需求规格说明编写小组，分工到具体部门组织编写。但是李封坚决不同意。眼看调研时间就到，蓝兰公司应该怎么做？如果按照李封的做法，应该做什么准备？李封坚持这样做，到底有什么道理？有一个什么妥协的办法吗？张成迫切想知道。
提前做好"功课"很必要
◎ 点评专家
张欣 北京大学联泰供应链研究与发展中心执行副主任
绎明宇博士 赛迪顾问项目咨询总监
王磊 IDS Scheer中国副总裁
张振坤 凌云科技集团有限责任公司信息管理中心主任
张欣 北京大学联泰供应链研究与发展中心执行副主任
在回答案例提出的问题之前，我们必须了解与需求分析有关的一些基本理论问题。
提前做好"功课"很必要
首先，了解需求分析的重要意义。其一，需求分析是企业IT建设的一个基本环节，是联结企业IT规划和IT实施的重要纽带或桥梁；其二，需求分析是企业IT战略的详细表述，也是IT价值的根本所在；其三，需求分析是企业的一次管理改进过程。
其次，了解需求分析的演化趋势。我们经常讨论企业信息化失败的比例有多高。其中一个很主要的原因就是需求分析没做好。一种情况是IT项目甲乙双方由于知识、能力、策略或管理等方面的问题未能做到无缝沟通。
另一种情况是，尽管甲乙双方沟通不错，但需求分析或许只是对管理现状的一次简单呈现，未能解决企业管理方面存在的根本问题，或是提得过于理想，导致项目过于复杂，实施周期过长，最终让双方丧失信心。
这些问题推动了需求分析的方式方法发生演化：一是IT服务方的需求分析责任人越来越多地由管理顾问来担任；二是IT项目双方合作得越来越紧密；三是随着质量管理、项目管理技术的应用，需求分析变得越来越规范；四是随着软件工程理论的发展，需求分析的方法论也发生重大变化。比如，引入OOAD(对象导向分析设计)思想并结合UML为业务需求建模。
再者，了解需求分析的主要内容和实施步骤。需求分析主要涉及功能性需求与非功能性需求两类，并以功能性需求为主。
一个需求分析详细回答三个方面的问题：一是企业的现状是什么(As-Is)；二是企业IT建设的目标是什么(To-Be)；三是从现状到达目的的最佳途径(方案)是什么(Best Solution)。那么，如何完成上述三个方面的准备呢？
首先，我们要了解需求分析的范围。一是功能范围。是一个ERP系统，还是一个独立的财务管理系统？二是业务范围。比如，一个管理会计功能模块可能只用在整车制造环节，也可能覆盖全部零配件制造环节。三是机构和人员范围。一个会计核算系统可以只要财务部门负责数据维护，也可以开放一些数据接口给生产、采购、仓储等部门。
其次，确定需求分析的层次。需求分析主要有两个层次，一是面向系统开发的需求分析(要变更或改进，需要较大的工作量。)；二是面向系统配置的需求分析(变更或改进相对较容易些)。
再者，确定需求分析的模式(方法论)。需求分析的模式受三个因素影响：编制需求分析的指导思想、编制需求分析的工具、软件服务企业的质量管理体系和项目管理体系。
了解了IT项目需求分析的范围、层次、模式之后，我们再结合项目甲乙双方的知识和能力作出判断，有时可能需要第三方的协助。 要占取主动地位再回到蓝兰集团的案例上来，那么，需求分析究竟该谁来做？
1、案例中提到，"在签约的时候，曾经和软件公司讨论过，需求调研由顾问按照提纲进行访问，然后整理出文档供(甲方)确认"。那么，既然已有合同约定(包括口头约定)，双方就应该按照约定的方式和步骤实施需求分析。
2、如果事先的约定可以变更，那么，我们再来看李封的建议。可见，其中存在几个重大的逻辑缺陷：首先，如果顾问只是到现场对业务部门的需求责任人进行"模块需求规格说明书"编写培训，那么，就无法对蓝兰企业做深入了解；其次，短暂培训是否就能让蓝兰公司的需求责任人员具备编写需求分析的能力值得怀疑。
另外，李封说，"顾问用四天时间对提交的需求规格说明书进行批改。"那么，乙方顾问根本没有对甲方进行过详细调查，怎么能在四天内完成对甲方需求的批改呢？最后，对甲方需求与乙方标准产品之间的"差距"，是更改甲方需求，还是更改产品来弥补？也难有定论！
3、针对这种情况，蓝兰公司不能让本来的主动地位变成被动，更不能在需求分析环节失去把握能力。而应该依据笔者提出的分析模型或其它类似的分析方法对自己和乙方的知识、经验以及承担需求分析责任的能力做出判断，并据此来决定是接受还是否定李封的建议，甚至，当认为对方的知识、经验、能力和责任心值得怀疑时，还可以取消与乙方的合作。
明确合作双方的责任细节
明确合作双方的责任细节
绎明宇博士 赛迪顾问项目咨询总监
蓝兰集团遇到的问题是企业在信息化建设过程中很常见的问题，主要原因是由于甲乙双方在项目合作签订过程中，对一些细节的工作责任没有明显地界定而导致的。由于蓝兰集团是传统企业，对信息化工程的过程和内容均不太熟悉，所以往往就会出现前期工作没有考虑到的问题出现。
要回答业务需求分析工作应由哪方来承担，就首先搞清楚信息化工程的内容，以及业务需求分析工作在整体信息化工程中的位置，这样才能明确此工作应由谁来完成。
一般来说，一个信息化工程包括前期的系统分析、中期的系统实施、后期的系统运维与优化工作，其中本案例中引发甲乙双方矛盾的"模块需求规格说明书(不同企业对此有不同的称谓)"属于前期工作(系统分析工作)的内容。
系统分析工作包括业务需求分析和应用系统分析两大部分，这两者的关系是根据企业业务现状以及信息技术特点而演化出来的新的业务需求(也就是业务流程重组或优化结果)，推导出为信息系统所能识别的软件功能模块及其相互关系(应用软件运作模型)。也就是说，业务需求分析是业务分析(也包括管理分析)过程，而应用系统分析是软件"编译"过程。
业务分析过程对于整个企业信息化过程有着关键的导向作用。分两个阶段工作，首先是企业供应链管理的现状描述过程，其次是企业供应链管理模式优化和重组过程，前者也是后者的前提和基础。
对于"模块需求规格说明书"的内容的界定首先就要指明，它只是包括企业供应链管理的现状描述过程，还是包含整个业务分析过程。
如果它只是企业供应链管理的现状描述过程，那么蓝兰集团供应链系统分析过程只进行了第一步，还需有第二步的工作，也就是说，还需要二次需求确认环节。如果它包含了整个业务分析过程，则单靠蓝兰集团现有人员的技术力量显然是不现实的。所以，我们可以把"模块需求规格说明书"的内容的界定为蓝兰集团供应链管理的现状描述过程。
有了这个前提，才能引出蓝兰集团供应链管理现状描述工作承担者的问题。实际上，对于企业信息化系统分析工作，并没有统一的模式。有时是甲方企业来承担，有时是乙方软件商(或集成商)来承担，有时是第三方信息化咨询公司来承担，另外，在实际操作中过程中，往往是这甲乙双方，或甲丙双方联合承担。张成希望甲乙双方联合项目组的方式，而李封是甲方企业承担模式，只不过乙方在其间给予部分技术支持。
由于双方存在着明显的信息不对称现象，所以应在双方签署合作协议时，由乙方向甲方提出，以供甲方根据自身的条件进行选择和确定。
本案例中，显然乙方并没有提出工作承担者问题，以致在合同签订后，引发出不必要的麻烦，因而总得来说，这造成此麻烦的责任在于南方管理软件公司。
如果合同中约定了"需求调研由顾问按照提纲进行访问，然后整理出文档供确认"，则李封提出甲方承担的模式显然就是违约(因为这种改变会涉及到前期业务分析过程工作量的巨大变化)，蓝兰集团有权提出中止合同，或要求南方管理软件公司履约。如果在合同中没有写明"模块需求规格说明书"由哪方来承担，则甲乙双方需重新进行协调，主要是测算工作量，以及重新确定合同金额(重签合作)。
另外，由于南方管理软件公司的项目经理对于此麻烦的产生有不可推卸的责任，而这种提醒工作是信息化工程中的常识性工作，乙方项目经理没有做的原因只有两种可能，其一是故意混淆概念，模糊工作量；其二就是没有此方面的工作经验。
不论是哪一种情况，对于蓝兰集团供应链管理系统的建设来说，都将是一种潜在的风险。因而，蓝兰集团可以直接向南方管理软件公司提出更换其项目经理的要求，也就不存在"妥协的办法"的问题了。
乙方并没有提出工作承担者问题，以致在合同签订后，引发出不必要的麻烦。
用"好工具"整合业务与技术需求
用"好工具"整合业务与技术需求
王磊 IDS Scheer中国副总裁
业务需求描述的环节，是一个信息化项目得以顺利进行的基础。而在众多项目中，该环节往往会出现前期业务需求的描述不够明确，从而导致项目后期不断变更需求设计的情况。
在项目中，对于业务需求的描述往往是由精通业务的人员进行的，但这部分人员通常又是企业内部最为忙碌的人员。因此，在描述业务需求时由于不能有充足的时间来反复斟酌，从而使得所描述的需求比较粗糙。
另外，咨询顾问要求业务人员用来描述业务需求的工具太过专业，使得业务人员无法用这些工具来很好地表达自已的想法。
比如，传统的做法是先画流程图再填需求调研表，这种画图加填表的方式等于是将基于业务需求梳理软件开发思路的工作全部交给了业务人员，这对于以业务操作为主很少接触信息化管理系统的人员来说，确实是勉为其难的。
正是由于上述情况，所以又会经常出现在项目后期业务人员不断提出新的业务需求或不断变更业务需求的情况，从而给咨询公司顺利完成系统的开发和配置带来很大的压力。
针对上述情况，笔者认为由业务人员进行需求描述这一点应该是要坚持的一个方向。咨询顾问通过调研整理出业务需求并请业务人员进行确认的做法，其准确性和完整性被大量实践证明是很差的。
问题的关键是应该给业务人员提供一个很好的工作平台，在这个平台上业务人员能够用业务的语言比较高效地进行需求的描述。而这种用业务语言描述出来的业务需求又能自动转成IT人员所要的技术信息，以便于咨询公司进行系统的开发或配置。
那么需要给业务人员提供一个什么样的业务需求描述工具呢？笔者认为，这个工具平台应该采用业务人员的工作语言。比如，描述一个业务流程，业务人员只要讲清楚做什么事，谁来做，目前需要用到什么样的数据或表单等即可，不用涉及专业的技术术语和概念。
但为了今后能基于此导出IT人员需要的信息，因此对于这些业务要素的描述应建立统一、标准、图形化的流程描述语言、方法和标准。比如，流程的操作、执行者、输入输出等要素的表达符号、形状、视图格式、关联逻辑等都应该有一个统一的规范和标准，流程要素的定义无二义性。 总而言之，应该有一套用业务语言统一起来的业务需求描述的建模规范，这套规范起到了联系业务人员与咨询顾问的作用，使得业务人员可以用自已的语言进行需求的描述，而咨询顾问又可以基于此得到所要的技术信息。
IDS Scheer 公司的创始人希尔教授早在上世纪八十年代就提出了将业务语言与技术语言相结合的ARIS业务流程描述规则。经过20多年的发展，ARIS业务流程描述的房式结构已经成为一种业界的规范和标准，被大量的企业所采用。
那么，有了一个好的工作平台后，是不是对于业务需求描述的责任全在业务人员呢？笔者认为，以业务人员为主进行业务需求描述是需要坚持的一种做法，但这并不意味着咨询顾问只是起一个收集和分析信息的作用。在业务人员进行需求描述的过程中，咨询顾问是应该全程参与其中的，咨询顾问应该起到一个指导和共同梳理的作用。
从某种意义上来说，是双方共同完成业务需求的描述。笔者反对的是传统的由咨询顾问对业务人员进行调研，然后由咨询顾问出具需求分析并请业务人员进行确认的作业方式。这种作业方式，由于业务人员往往只是动动嘴，因此对于需求的描述肯定是不够全面和深入的，这样必然会导致后期需求的大量变更。
综上所述，在管理信息化建设过程中，对于业务需求的描述应是由业务人员为主来进行，但同时应该给业务人员提供一个很好的工作平台，而且咨询顾问也应全程参与并起到指导作用。
应该有一套用业务语言统一起来的业务需求描述的建模规范，而咨询顾问又可以基于此得到所要的技术信息。
信息中心应是需求分析的主角
信息中心应是需求分析的主角
张振坤 凌云科技集团有限责任公司信息管理中心主任
准确分析各角色心态
在信息化建设的需求分析过程中，有几个主要的角色必须明确：
首先是企业的一把手。他的意图必须要搞清楚：上信息化项目的目的是什么，究竟要解决什么问题，什么因素促使他对信息化项目产生了兴趣。
老板既然有心想搞信息化，必定有其直接的原因。当信息系统最终偏离或达不到老板的意图时，信息化就不可能说是取得了成功。
当然，也会有无心插柳柳成荫的效果，就是说虽然没达到预期的效果，但毕竟解决了其它方面的问题，不过这对于老板积极性的打击也是很明显的。
其次是企业业务部门的相关人员，或者说是信息系统的最终使用者。他们其实并不关心信息系统能否解决老板所关心的问题。他们只是对系统是否好用，能否解决自己在日常工作中的问题感兴趣。他们所关心的是：最好不要改变传统的工作习惯，在不影响既得利益的前提下能减轻一些手工操作。只要达到了这样的目标，他们就会认为是好系统。
然后是信息系统的提供商，也就是软件公司，或者是所谓的系统集成商。他们关心项目能否按期完成，合同款能否按期收到。要想实现这个目标，对于他们来说，最好的办法就是把软件安装好后，经过简单的培训，甚至不培训，企业就能自己解决问题，系统能顺利运行。
他们最害怕所谓的二次开发，也就是满足客户的个性化需求。只要客户提出了个性化需求，相对聪明或者有实力的软件公司会在已有的功能里面找出变通的方案来代替，尽可能的搪塞敷衍。如果实在找不出能代用的解决方案，则会采用拖、磨等战术，让用户没有耐心来等，最终放弃原来的需求。
这种方法还有一种很堂而皇之的说法，叫做引进科学的管理方式，改变用户的管理模式，以最佳的流程来优化企业的管理等。这样做的结果就是用户总是感觉被糊弄，被欺骗。
说了这么多，系统相关的各个角色及心态都清楚了，那么再来回答需求分析该由谁来写这个问题，也就应该清楚了。
领会根本需求 占取优势
领会根本需求 占取优势
企业的战略意图当然要讨论，并且要认真分析。因为信息化的目标就是要为企业的战略服务的。
从文中可以看出，蓝兰集团要实现内部供应链的管理模式是主要目的，具体的需求就是集团统一接单，然后将订单分派给集团内部各子公司以及各供应商。
具体目标是建造一个统一平台，将内部供应链做透，以方便客户、业务代表检查和监督订单执行的各个环节。不知道以前蓝兰公司是怎么做的？是由各分子公司自己联系业务、相互独立经营？还是条块分割，相互牵制？客户、业务代表和公司究竟是如何对订单进行管理的？要改变过去的模式究竟应该怎么做，需要制定什么样的制度和流程，软件在这中间究竟要发挥多大的作用？
完全由业务部门来写需求分析，存在的风险在于：由于不理解软件公司所提供的专业模版的具体意思，就敷衍了事，随便对付一下交差，不能反映出实际的需求和真正的意图。同时也会对项目抱过多的幻想和期待，提出一些不切合实际的要求，目标太多以至于导致项目无法完成。
更多的业务部门往往会过于计较细微末节的东西，如报表格式、录入习惯等。还有就是对传统工作方式的坚持和固执，不愿意变革。如果严格按照这样的需求进行设计，所做成的系统极有可能还是传统工作方式的电子化，所谓的穿新鞋走老路，偏离信息化项目真正的目标。
需求分析对于软件公司来说，其意义不亚于合同的商业附加条款。既然已经明确了要进行适应性改造，南方公司李封的做法，实际上是在回避问题。
"由顾问到现场对业务部门的需求责任人(大部分是管理人员)进行"模块需求规格说明书"编写的培训，然后确定实施与开发任务。"这里面的风险不仅是业务部门对专业术语的理解偏差，更主要的是南方公司的调研提纲，完全是按照自己已经设计好的软件架构和思路来"引导消费"，有可能会出现目标的偏差，能否响应公司老总确定的目标就很难说。或许他们就根本没考虑老板的最原始需求。
当然这样做的结果是：对南方公司而言是以自己已有的软件模版和框架为蓝本，对业务部门进行培训，由业务部门来写需求分析，最终双方签字画押进行确认，以此来引导、引诱乃至绑架最终用户的需求。这样可以使得将来的系统不至于陷入无休止的需求变更和二次开发的泥潭里，项目的最终目标相对明确，以利于最终能顺利脱身。
比较合理的做法是，企业的信息中心要真正发挥出主导作用。要和老板多交流，认真分析和领会老板的意图，因为这才是最终的目标、最根本的需求。要对软件公司所提供的软件解决方案进行分析，看到底能符合到什么程度，有多少问题能够解决，还有多少根本做不到。
如果和目标偏离的太多就不要搞什么需求分析了，干脆再换一家公司来做。如果偏差不大，绝大部分功能都能实现，则坐下来和软件公司的实施顾问一起研究，进行系统的模拟运行和推演，在确认可行的情况下，拿出具体的实施方案来给老板汇报，交给业务部门讨论。
基本原则就是确保最终目标不变，并尽可能照顾到业务部门的操作习惯等需求，以此来确认最终的实施和开发内容。只有这样做，系统才能达到预期的目标。
基本原则就是确保最终目标不变，并尽可能照顾到业务部门的操作习惯等需求。
网友评论