为了满足业务需求，许多公司都在积极提高IT能力，让IT开发团队加入其服务的业务部门，而此时他们正在对更多的基础IT服务人员实施集中化管理。诚然，让IT进入业务部门有利于使开发工作与业务目标保持一致。但是，这样也会带来一个不良后果，即IT开发人员分散在各业务部门和职能部门之中，项目协调和区分项目优先次序变得更加困难。在两个业务部门中，独立的IT团队使用不同的供应商和技术，可能会同时开发出相似的应用软件。业务部门可能对短期成果感到满意，然而，整个公司却可能因开发成本高昂、绩效管理不善以及跨部门功能部署困难而蒙受损失。

　　另一方面，主要以集中化促进效率的公司在应用软件开发中不够灵活、速度较慢。这种情况下，所需功能部署的长期拖延会令业务部门受挫，IT部门则会被视为反应迟钝的官僚机构，业务要求的黑洞。

　　那么，公司如何才能在软件开发中既保持灵活、又不失效率呢？一些处于领先地位的公司正采取分离供应与需求的方式来解决这个问题。他们同时建立了IT供应部门（如卓越中心或共享软件开发小组）和需求部门，后者充当业务部门与IT之间通晓技术的媒介，负责协调各业务部门的要求（图1）。在这种模式下，需求部门通常设于IT内部，直属于首席信息官，它对业务部门和IT都负有责任，可以由两个部门共同管理。需求部门与各业务部门密切合作，以了解它们的需求和机会。然后再与IT供应商协作——这些供应商有时是内部软件开发团队，有时则为外包供应商——将业务需求和机会转化为新IT项目的技术规范。

　　建立这种需求管理模式具有数种优势。首先，这种模式为业务部门提供了专业采购人员——即深谙客户需求、熟悉供应市场状况的技术型经理，从而在内部引入市场机制。在一家大型金融机构，业务部门认为尽管IT部门反应迅速，但开发人员却把过多的时间花在部署低价值的改进上，根本没人考虑公司的技术投资应如何发展这种更为重要的问题。后来这家公司设立了IT需求部门，解决了这些问题。公司规划技术路线的能力得到了提高，并能更好地追踪IT与各业务部门之间的责任履行情况。

　　这种组织结构的第二个优势就是能更有效地协调不同业务部门的需求。如此一来，需求经理就可以大批量采购IT服务和供货，既提高了公司IT资源的利用效率，避免了重复，又有助于建立标准，鼓励再利用。短期优势包括更好地协调工作和排定工作优先顺序；长期优势则包括加快整个企业范围内功能部署的速度、令技术路线图更为明晰。一家欧洲电信公司采用了这种IT及网络管理需求模式，其常规项目投资回报率增长了一个数量级。

　　另外，内、外部IT供应商都是与更加通晓技术的客户打交道，因此交付的速度和质量都会有所提高。一家将供应与需求组织分离的软件提供商在六个月内显著提高了客户满意度，很大程度上是因为需求组织为业务部门充当了准备充分的客户利益代言人，能够与供应组织进行更有效的合作。

　　这种模式还可使IT专业人员大受裨益。将开发人员整合到为数不多的几个供应组织中，使其将精力集中在专业知识上，专业发展水平就会得到提高，而IT人员的职业道路也会变得更加宽广。此外，他们也喜欢与技术水平更高的客户合作。

　　除以上运营优势之外，还有几种发展趋势也在加速供应与需求的分离。外包和离岸供应商越来越多，这些选择增加了供需分离模式的吸引力，因为供应商既可来自企业内部也可来自外部。公司不再受限于内部员工队伍的规模，因此，稳定的需求管理变得更加重要，以免业务部门因使用多个外部供应商而超支。另一发展趋势是IT日益“产品化”。换言之，IT 使用一个有限的基础设施产品组合实现运营的标准化，不再按订单构建系统。运用这种方法，制订系统或产品规范的设计者就能集中精力解决业务问题，将硬件、软件和存储的要求交由供应商决定。第三，IT 及其不断发展的能力对业务流程的影响越来越大，因此，工作流的改变与IT变革相伴而生、如影随形。举例来说，为一个销售队伍实施一套现代化的客户关系管理 (CRM) 系统，几乎总是要求对工作流作出相应的调整，而需求组织将能很好地协调流程与IT变革。

　　凭借早期与一些公司合作的经验，我们可以确定成功建立需求管理和供应组织的几个要素。第一，公司必须了解需求管理的普遍方法以及新组织可以如何改进这些方法。此外，必须正确构建新组织，并让合适的人才担任重要的新角色。需求经理必须了解内部客户的业务流程和IT组织的能力。需求经理应与业务部门和业务流程协调一致，并负责满足业务要求。最后，需求组织应集中协调公司各个部门提出的需求申请，同时还要管理一系列IT供应商——从内部员工到全球各地的外包商。

　　妥善设立需求组织。

　　分离需求与供应时，有些公司将重点放在供应组织的改进上。然而，需求组织才是这一模式与传统IT架构之间的区别所在，而妥善设立需求组织难度更高。

　　大多数情况下，业务人员和IT很快就能看到需求组织的潜在利益，因此，做出必要的调整通常并不困难。划分权责、排定优先顺序所需的时间可能更多（也需要更多协商），但是，需求团队与IT及内部客户开始合作后，此类因素也会随之发展变化。根据我们的经验，有四种做法可以助需求组织更轻松地完成使命。

　　协调需求组织与业务部门

　　需求组织须与业务部门协调一致，充当客户的忠实代言人，澄清他们的真实意愿——有时，他们口头所说的与实际意愿并不相同。所以，最理想的结构是为每个业务部门设立一个需求组织，并联合管理这些需求组织，以协调处理各种要求。需求经理必须对客户流程和软件开发有着深入的了解。这样一位经理的理想人选要有软件开发背景和担任管理职务的愿望。这些经理应不断接受综合管理技能或实践的长期培训，如六西格玛、项目管理和商业项目策划等。

　　与之相对，供应组织的构建则并不局限于业务部门，而是围绕更加广泛的能力和业务流程（如销售、运营和后台职能）或在线交易及数据仓库等技术构建。供应组织要与协调各业务部门相似要求的需求组织合作，因此，供应组织能够着眼于整个公司而非单个业务部门的最佳利益，做出广泛的决策。比如，从事多元业务的企业中，各部门很难对客户形成一致的看法。然而，即使业务部门继续使用独立的销售团队，一个以销售为中心的供应组织也能对整个公司的 CRM 平台实施有效的监督。

　　让需求组织对业务流程负责

　　由于IT解决方案对业务流程的影响越来越大，企业应将工作流设计的任务交给了解基础技术和关键业务“痛点”的团队负责。需求组织拥有确定业务需求和要求的专业知识，非常适合与业务负责人合作，切实有效地利用 IT，保证流程顺畅运行，避免在流程失败时不得不付出高昂成本进行修正。

　　虽然这种结构实施起来可能存在困难，但是，把业务流程设计工作交给需求组织却是值得的：这种结构将确定流程和要求的工作交给了一个能平衡业务部门利益和技术知识的团队。若由技术人员来制订要求，设计则可能过于复杂；若过分强调业务需求，设计则可能强调个例，当业务需求发生变化时，设计会变得过于具体而缺乏灵活性。想一想2001年9.11事件之后美国各银行实施的灾难恢复设计吧。那些决策者们急于提升业务连续性，所以在冗余与改进型架构之间选择了前者。由于这些决策都基于对短期业务的考虑，因此，各家银行并未将其大型投资的价值最大化。如果有需求组织这种居于有利地位的流程设计机构，就能有效地管理需求，在短期需求与长期稳健发展之间取得平衡。

　　委任需求组织确保需求合理化

　　多数公司拥有过多的功能相似的应用软件，因此需要周期性地删减应用软件组合——这是一个费时耗财的过程。需求组织可以在投资时减少IT项目和应用软件的数量，从一开始就防止这种情况的出现。经理应与需求组织成员定期召开会议，审核项目领域、明确协作机会，从而避免“筒仓效应”。在此过程中，需求组织将负责帮助公司合理分散投资。如果没有这种委任行为，有利可图的业务部门可能将过多的资金花在IT上或者无法与公司其他部门共享解决方案。

　　授权需求组织管理供应商

　　需求组织应将业务部门从管理众多内、外部IT供应商的繁重任务中解脱出来。通常情况下，IT 供应组织中已经安排了拥有必要技能的人员，对内部团队或外包资源进行管理。最好的办法是将这样的人才引入需求组织，但是，即使这种方法也未必总是简单易行：他们需要接受新的培训，学习业务技能，掌握协调管理众多关系的能力。在一家物流公司，一位经理从IT供应部门调任IT需求部门，这位经理过去习惯于精细的管理方法（比如如何最有效地运行服务器）。他需要花好几个月才能认识到，新的工作岗位要求他关注范围更广的服务水平和效率。

　　除了提供上述成功因素之外，公司还须优化衡量成功的指标和项目管理中的一些关键流程。需求组织的成功指标应以效能和客户满意度为中心。对供应组织来说，成功指标则依然以成本效率和质量为重点。另外，公司还须调整其流程，尤其是项目投资和软件开发流程。

　　使业务流程适应新的模式

　　在传统模式下，业务部门通常地为部门内部的软件开发项目提供资金。尽管各部门通常对投资回报表示满意，但整个公司却可能支出过多。在引入需求管理组织之后，业务部门及其需求团队应共同制定能力战略，阐明应如何调整应用软件组合才能达到业务目标。基于这一战略，整个需求组织应与各业务部门进行协调，从整个公司的角度做出投资决策，不但涵盖个别项目，也包括有关架构和应用软件组合的长远决策。

　　另外，需求－供应模式还要求对软件开发流程做出调整。一般情况下，项目需经历五个阶段：愿景、设计、构建、测试和部署（图2）。在传统模式中，首先由业务人员提出愿景，然后由IT部门进行设计、构建、测试和部署。不幸的是，最终交付的产品未必符合业务部门的愿景。在需求－供应模式中，不管最初的想法来自业务部门、需求组织还是供应组织，愿景阶段都由需求部门掌控的。需求团队携手业务部门和供应组织，共同探讨创意、想法，并最终负责将提出的想法转化为业务要求文档。此后，由供应组织负责管理其余几个阶段：技术设计、构建和测试。需求组织将参与这些阶段的工作，必要时可让业务部门也参与进来。对开发人员来说，无论有什么问题或想法，通过这种方式，他们都能找到业务人员的最佳代理人。在部署阶段，由业务部门实施验收测试，这与传统模式并无二致。但不同的是在出现问题时，需求组织可以提供专家意见。

　　避免错误

　　组建需求部门需要耐心和毅力，而且并不适用于每一个公司。比如，业务需求极其稳定或者只有一种核心业务的公司就没必要建立这一模式。为确保IT需求正常落实，公司应明确界定需求团队的角色和职能范围，确保所有相关人员都清楚地理解有关细节——包括业务部门、需求部门和供应部门的所有人员。

　　常见错误包括让需求组织过分关注某个业务部门，或者过分关注供应组织的流程。每种错误都可能令需求团队偏离其更重要的使命，即整个公司的效率。当然，就关键标准进行透明的沟通也是至关重要的——不但需求和供应部门之间要做到这点，也要与负责跟踪新组织绩效的高级管理人员进行这样的沟通。

　　随着企业开始部署并实验这种方法，我们期待这种模式的扩展。产品复杂的消费品公司可以引入客户代言部门，负责向供应部门传达客户需求。IT 之外的业务部门也可采用这一模式。比如，法律部门可以用相同的方式为内部客户服务。无论何种情况下，良好的需求管理必将帮助众多企业提高总体生产率。

　　转向需求—供应模式的组织，其生产率和确定投资的优先顺序的过程都会大大改善。组织复杂程度降低了，要求更加明确，对IT的理解也加深了。最重要的是，业务人员将开始从投入的资源中获得最大的价值。