在一个理想化的世界里，CIO们能够从容应对源源不断的各种新需求，让公司获得新的或增强了的业务能力，从而满足其客户——IT为之服务的业务经理——的期待。

　　理想情况下，各种需求都具有清楚的描述和充足的细节，因此很容易估算出需要投入的资源;在交付解决方案的时候，每一种新功能都与最初的需求描述相吻合。资源的均匀分配将不是问题，因为对各种新的IT业务能力的需求会被依次提出。技术更新周期也绝不会妨碍公司的运作，因为各种IT基础设施和业务解决方案平台都将拥有良好的结构设计、抽象性和模块化。通过采用标准化和一致性的架构，解决方案的复杂度会被降至最低。

　　这样的话，公司就能采用各种各样的新技术，而这些技术都将具有令人满意的成熟度、稳定性和投资回报。CIO们从此就能过上幸福的生活了。

　　但在现实世界中并不是这样。

　　现实中，公司的运营并不具有简单的周期性，因此通常看来各种需求总是源源不断地来自四面八方。CIO们很难对这些需求进行优先级排序，也就很难有效地分配各种资源。对各种新能力的需求又是如此迥然不同，以至于很难采用一种前后连贯并且设计良好的解决方案平台和技术基础架构。

　　业务经理在提出需求的时候，并不仅仅说自己需要“什么”，还会提出应该“如何”建立解决方案。各种厂商也都在向IT部门兜售产品，从而破坏了现有的各种标准，增加了操作的成本和复杂度。

　　解决方案的提供途径由此变得纷繁复杂。CIO们被迫过上连续不断的麻烦生活。

　　没有灵丹妙药可以解决现实世界中的这些挑战。CIO们毕竟已经花了30多年的时间试图解决上述问题，他们都是聪明人，如果这些问题真的容易解决，就不会拖到现在了。但仍然存在一些经过时间检验、却未被广泛认识到的实践经验，能让CIO们的生活变得轻松一点儿。采用这些经验并不会让CIO们的生活变得完美，但会让他们减少许多困扰，并让IT为公司业务的成功贡献出真正的价值。

　　需求管理

　　最关键的一条实践经验就是，应该采用一种规定明确、容易理解和始终如一的需求管理过程，对新增或加强业务能力的各种需求进行协调。

　　对于新增或加强业务能力的许多需求都有通用或重叠的解决方案，但CIO们只有在分析了足够多的需求并看到了其中蕴含的模式之后，才能发现这些共同之处。这里的一个最佳实践就是CIO们应该主动出击——深入地了解公司的业务，与业务经理们探讨他们的需求是什么，并采用这些管理者所使用的专业语言。

　　由于IT并不总是受人欢迎的，上述最佳实践也并不总能轻易做到。但CIO们应该抓住其中关键的一点：要对公司当前的和长远的业务需求有一个整体的了解，并涵盖尽可能多的业务部门。这样一来，CIO在解决问题或提供解决方案时就能避免或尽量减少眼光的局限性，在向公司的其他用户提供或准备提供解决方案时也有机会做到重复利用。

　　除了要与公司管理者进行沟通，CIO们还应该设法了解业务的发展战略和期待的业务成果，从而对业务目标有一个更高层次的认知。这将有助于设定各种业务需求的优先级，从而更有效地分配资源。

　　竞争对手的相关信息是业务构思的另外一个丰富来源，因为可以从中获知公司的竞争对手认为哪些业务能力是值得投资的。IT部门搜集和分析这种信息通常比业务部门要容易，因为技术厂商经常会跟客户公开谈论自己正在为其它公司做什么项目。尽管这些厂商通常并不明确指出采用的是什么技术或者采用的原因是什么，但头脑敏捷的CIO们仍能做出成功的猜测。

　　另一项最佳实践就是CIO要对新增或加强业务能力的需求进行评估，看它们能否用新兴的、或已成熟但尚未被广泛采用的技术来满足。然而重要的一点是，不要直接跳到技术解决方案的细节问题上，因为这通常是由技术专家们来讨论的。

　　CIO们最好先理解哪些业务能力是公司管理者所需要的，然后才开始寻求解决方案。例如，公司的管理者如果想知道在任意时刻有哪些员工在办公室以及每个人是否都在工作，就需要人员在场及身份确认服务，尽管他们此前可能从未听说过这种服务，或者不明白技术专家们用来描述这些服务的专业术语。

　　当业务经理提出新的或有待增强的业务能力需求时，CIO要让这些需求保持合理化。要做到这一点并没有捷径，这将是IT部门与业务部门之间一个持续不断的协商过程，因为业务部门想要获得的资源总是超出IT部门所能正常提供的。

　　CIO们必须把这些需求限制在合理的范围内，使其与投资成本、推向市场时间、人员技能等现有的能力相匹配。在这个时候，IT部门就应该并且有能力推动业务部门提供资金，用来塑造标准化的和具有平台一致性的新能力。标准化和平台一致性不仅在技术上提供了更多的方便，还能让业务部门从投资中获取更多的新能力，并更快地发挥这些能力的作用。

　　接下来，CIO就应该去寻找资源开销最小的可行解决方案，以满足各种新需求和累计的总需求。这时就会用到“通用业务服务”，也就是在与客户合作的时候，对于他们提出的需求，最好能够判断出哪些是具有普遍性的，哪些是为了实现特定业务能力而独有的。

　　一位CIO能拥有的最大财富就是他所带领的解决方案架构师团队，因为这些架构师对业务非常熟悉，也知道能采用哪些技术来交付一个解决方案。CIO们还应该让公司所实施的业务过程尽量符合行业标准的业务过程模型，以便更好地理解和优化公司的信息流和工作流。

　　尽管CIO们希望看到每项业务能力都能通过组装通用的解决方案元素——例如消息传递、目录服务、身份验证和安全等横向能力——来获得满足，但现实并不是这样。

　　一些解决方案元素只对一两个业务领域是通用的，或者干脆是某一领域所特有的——例如信用记录检查、售后保证管理或市场开发等纵向能力。随着对解决方案架构的调研不断深入，业务及解决方案架构师们必须重视每一项单独的元素，因为它们的独特型可能造成更多的开发成本以及全程持有的总费用。

　　在上述工作完成之后——其间可能经过多次迭代才与客户达成了可行的协议，就将产生一个解决方案的架构，其中包含了被支持的业务实例，以及对投资日程和回报率水平的要求。

　　通用性vs.独特型

　　这时，解决方案的架构设计就要从业务领域迅速转移到技术领域。技术架构师们知道哪些技术是可用的，并了解它们在功能、效率和适用规模等方面的特点。因此CIO就需要召集一个技术架构师团队，选择出实现解决方案架构所需要的技术的最小集合，这本质上就是设计出一个最优化的技术供应策略。这时CIO们又要努力判断出技术架构中哪些部分是通用的，哪些又是独特的，并考察这种独特性的成本和价值。为了容易管理，CIO们必须对通用的部分和独特的部分进行分隔。但随着一系列平台架构的开发，团队必须对各项单独的架构进行重新组合，以便确保这些架构整体的连贯性和一致性。

　　通常需要很多次努力才能就上述工作达成一致，而CIO们常常要返回到业务领域，有时是作为业务经理的代理与技术架构师们进行协商，有时又要直接与业务经理进行协商，直到技术架构被最终设计完成。

　　最后一步就是为要采用的技术制定出详细的供应决策——例如确定是自己开发还是直接购买。

　　在上述整个过程中，CIO们能够创造一个全局性的视图，其中涵盖了业务能力需求、解决方案元素和技术的实现策略，这将有助于支持后续的解决方案生命周期管理和技术更新。

　　因为CIO们清楚各项业务能力依赖于哪些解决方案，以及这些解决方案需要采用哪些技术，他们就能对解决方案的改变和升级可能造成的影响做出可靠的分析，并确定如何让这些更改更加简单并且破坏性更小。在必须进行改变的时候，他们清楚哪些人将受到影响，就能进行相应的沟通和安排。

　　一旦上述工作组合被确定下来，还有最后一项任务要去做：确定合适的投资回报参考模型以及对每项工作完成情况的期待水平。

　　并不是每个项目——不论它对整个计划有多么关键——都能带来同样水平的投资回报，对每一项工作的论证都应该包括以下几点：谁将从中获益?获得的效益是多少？获得这些效益的成本又是多少?在工作完成之前，CIO们必须能够回答所有这些问题。

　　这不是一项容易做到的准则，很多IT部门都没有很好地遵守。有大量项目在启动的时候甚至没有通过“是否有人能从中获益”这个测试，因此它们最后的失败也就是必然的了。

分类： 项目管理 管理工具 软件工程