过去，IT风险管理常被忽略或仅仅作为一个单纯的技术问题，但是，现在它已经成为组织治理的问题，是一个涉及到政府部门、监管机构、外部审计、技术服务提供商、董事会与管理层及所有利益相关者的问题。SOX法案更是通过内部控制有效性声明和严厉惩罚将法律与IT风险问题绑定。鉴于此，谨向上述人士推荐此书，相信本书的出版对于推动IT风险管理领域的发展有着非常积极的意义。
4.3.3 常被曲解的项目风险因素
上面考察的几种项目风险因素实例对发现那些非项目固有的一些特性，建立更好的框架，探索用不同的方式来进行管理都是非常有价值的。
同上述几项风险因素类似，我们认为下面几种风险因素也同样重要：
● 需求的稳定性。
● 项目团队的技能和经验。
● 采用的技术类型和数量。
我们认为这些因素将会不时出现在项目生命周期的各个阶段，在整个项目生命周期内，要求注意克服这些因素，以降低可能对机构带来的潜在风险。
1. 需求的稳定性—— 灵活性的需要
很多领域的IT项目失败都同项目范围的变化有关。冻结项目范围也许并不恰当，可是这个选项之外，还有什么其他的办法供我们去选择吗？深入地思考这个问题，对我们来说是非常有意义的。项目已经满足了原定的规范要求，但却无法满足当前的业务需求，在方案交付的过程中，什么时候可能会发生这种情况呢？
把项目的风险因素都找出来，并且逐个把它们都说清楚—— 风险的起因与后果，这是很有用的—— 比如，由于项目范围的扩大可能会造成整个项目被迫推迟交付，费用也会增加。针对这项风险，就有必要采用一套方法来管理需求乃至整个项目的范围。对项目经理来说，这套方法就同“面包和黄油”一样，是项目管理的必需品。尽管来自于项目监督的刨根问底式的问题也足以把这个问题搞得一清二楚。
通常，采用“扩大范围、宁多勿少”的方法是避免后期项目范围变化的方法之一。但是，与之相反的观点也有点似是而非：积极参与的用户群将持续不断地为既定的项目规范提供改进意见。
但从IT方案供应商的角度看，未必就把项目范围的扩张看成一个风险。相反，他们也把它看成一个机会。项目“已定价”部分将按时交付，接下来的变更需求就可以确定下来，带来的利润也一定非常可观。从另外的角度看，增加投入使新版本的应用能交付更多有价值的功能，也是一个改进现有系统的机会，同样会带来巨大的商业价值。
总之：
● 范围的扩展未必就是坏事。
● 在整个项目生命期内，及时发现项目范围变更所造成的影响是非常重要的。尽管对单个项目来说，采用什么样的方法去管理项目范围还需要仔细斟酌，但几个可以参照的通用模式还是能找得到的。
● 扩大项目范围也为我们带来机会—— 解决方案将会为我们带来全新的、具有商业价值的、与众不同的成果—— 尽管还需要同费用一起加以考虑。
2. 技能和经验—— 依赖于团队
从单个的项目角度考虑，在较短的时间内获得一个具体的成果，其实是保护项目实施团队安全的最好的做法(Jiang和Klein，2000)。他们不得不小心翼翼，直到方案上线才敢“松口气”。
但从机构的角度来看，这未必是“正确的做法”。的确，不是每一个项目都有团队。今天也许A团队被解散了，人员也离开了，或者调去从事其他更重要的工作了，那么会发生什么样的事情呢？
一个项目团队适当吸收一些技能平平的人有时还是必要的—— 至少，这些技能平平的人的加入还能让这支团队的平均技能保持在一定水平上—— 对这种项目团队来说，一方面要有效地利用团队的知识和技能，另一方面还要让团队起到员工训练基地的作用。
同那些老手相比，新手或者没什么经验雇员的“风险”只会发生在他们进入项目团队之后。但我们应该看到，他们也为项目带来了新的视角，在项目的研究阶段会给项目带来很多积极的方案选择，这确实是一种难得的资源。他们从其他开发环境所获得的开发经验现在是发挥作用和优势的时候了。积累的经验在这儿成了新技术技能，对正在进行的项目而言，尤其显得重要。
总之：
● 一个团队不会同时做所有的项目。
● 项目部署为员工的在职培训提供了场所，也为培养“明日的团队”提供了一个难得的机会。
● 新的技能需要新的血液。
3. 技术的数量和类型—— 你要认识的魔鬼
和员工的技能、经验风险因素相似，从“风险检查清单”里我们还能发现另外的一种强烈的暗示，那就是使一个项目里，使用的技术种类越少越好。无论如何，对我们来说，新的技术都是未知的，它们未必能像我们期望的那样发挥作用。
当然，经历较长的时间以后，新的技术一定会在系统环境中出现。因为，我们又要同时避免操作风险的增大—— 新平台不支持旧技术。
这个问题带给我们的最大挑战在于，如何在创新压力下寻求新老技术结合上的某种平衡。将新老技术相结合可以让我们找到一条交付方案的捷径，让我们可以直接使用新技术，同时也保留着随时“退回到老技术”的选择。
在我们考虑在一套方案里使用多少技术时，有一点非常重要，那就是要考虑技术的兼容性和协同工作的能力。也许我们并不能指望多家供应商的方案“穿插”在一起还能很好地工作。相反，来自单一技术供应商的多个方案也许还可以通过产品之间的接口，结合在一起协调工作。
但作为一条原则，应该谨记：早期版本的技术产品应该尽量避免使用。原因是这些技术所依赖的标准可能刚刚出现。这就是说，在一个开放系统环境下，使用10种左右的技术方案构件是比较适当的，每种构件都作为综合解决方案的一部分发挥其最佳功能。例如，三层WEB方案“栈”可以包括下列组件：
● 前端—— 分布式的客户端，表示层模块或者薄客户层“浏览器”(1)；中心服务器，表示层模块或“Web服务器”(2)；
● 应用逻辑—— 遵从J2EE规范的客户化应用逻辑(3)，运行在商用的“应用服务器”(4)上的第三方和开放源码软件构成的解决方案(5)；
● 数据管理—— 关系型数据库管理系统(6)；
● 安全基础设施—— 防火墙和入侵检测与监控(7)；
● 管理报告工具(8)；
● 系统管理工具(9)；
● 备份和恢复机制(10)。
所有的上述构件都分别驻留在不同的机器里，运行在不同的操作系统上。在这些构件的背后可能还有一些适配器和中间件层来保证彼此之间的耦合和连接。
方案做得这么复杂也不一定就是件坏事！拟采用的方案同以前的方案(单纯的单一构件)相比，在可扩展性、集成性和将来的可移植性方面都有了重大的改进。
同新技术有关的一个重大警告信号是：采用和应用那些很多信息技术专业人士所热衷的新技术所获得的商业利益并不大。对每一波的新技术而言，只有有限的机会之窗能使极少数的信息技术专业人员变成在职业和收入方面领先大众的所谓“专家”。在采用新技术的时候，可能会使“第一个吃螃蟹”的机构陷入“试验和犯错”恶性循环，但却会为个人成为所谓的“专家”指明了道路。就好像一个风险投资者打中了市场却被别人拿走了奖金一样。
4.3.4 可以选择的交付模式及其风险特征
当今最通用的两种交付模式中，一种称为“经典”的瀑布方法(即结构化系统分析和设计方法及其变种)，第二种则是更现代的迭代方案交付方法(即统一流程及其变种)。每一种都有其独特的风险特征、管理要点和值得关注的地方。
“经典”式瀑布方法类似一条生产线，其中的每项任务都有定义好的“上游”和“下游”关系。下游任务必须等待上游任务完成以后才可以开始。上游产生的任何缺陷都会被带往下游。重新生产的过程冗长而且开销巨大。从好的方面说，这可以比较容易地定位所有问题(在最小的时间里返回到那个环节)，尽管断开环节之间的次序依赖关系也是很困难的，因为这会受到来自产品“按时上市”要求的挑战。延迟和厌恶的冲击—— 包括找出罪魁祸首—— 将会发生在瀑布模式里，尽管责任人是明确的，但解决问题的办法就未必。
瀑布模式的管理要点和值得注意的地方主要在于每一个完成步骤的(退出判据)检查点。
在更现代的迭代方案交付方法里面，内置了规范的“螺旋”机制。每一个“子”方案都需要进行分析、设计、构造和测试—— 然后才是集成。尽管类似的瀑布模式常常也会引入到“末代循环”次序关系里，但是在开始建构整个方案之前，对分析和方案设计的完备性并没有特别的要求。理论上，方案中最困难的部分应该是迭代的开始阶段—— 如果必要，可以把未解问题保持在最长的迭代循环中—— 而最简单的方案构件则会在最后一轮的迭代过程中加入。在这种模式下，尽管每经过一次迭代，交付的确定性都会获得提升，但是在项目早期阶段期望获得可靠的交付估计仍然是非常困难的。延迟和厌恶的冲击—— 包括找出罪魁祸首—— 通常在这种模式下不会出现。而这种模式的最大风险在于经历了持续的迭代以后，总是显示只完成了总工作量的90％。
尽管从逻辑上讲，还可能会出现一种情况，即在每一次重要迭代之后都要像整个方案结束时所做的一样，需要进行认受性测试。但是值得欣慰的是，在这种模式下，管理上并没有那么多突出的问题，需要关注的地方也没那么明显。
4.3.5 开发之外—— 项目的保障和升级
大多数讨论到IT项目风险的文献都把焦点集中在新软件的开发上。但在很多大型机构里面，更普遍的IT项目还是对现有系统的修改，当然也可能伴随着少量的新软件开发。那么，这些软件升级类项目的风险形式会是什么样的呢？
1. 升级
借助现有的系统可以把IT项目的相关风险降到最低—— 技术是了解和熟悉的，还有现成的专家负责。而且还很容易估算出时间和费用成本。为了保证质量，还可以继续采用很好的测试方法和测试计划。
然而，这类项目也面临着很现实的风险：
● 因为升级，可能会引入新的缺陷，从而导致运行在现有系统上的业务中断。
● 可能为现有系统带来“过保障”风险，最后使系统更不灵活，更难以作出变更，就像绑在身体上的层层绷带一样。
想用昨天的架构来建构今日的方案，出现问题在所难免。在一群彼此关联的老系统的基础上，通过变更接口和相关软件来实施新的方案，时间和成本上的耗费将会使变更所带来的功能性成效大打折扣。一套结构上更清晰，耦合上更松散，也更符合现代潮流的技术架构将为我们带来更具可预测性、更有成效的、也更直接的功能提升。
2. 扩充与替换
那些交付商业价值很低，甚至根本不会带来利益回报，却因为某些原因不得不上的系统，在所有的IT项目中大概算得上是吸引力最小的了。那么，我们为什么还要实施根本没有商业价值的IT项目呢？
单纯从商业价值角度看—— 也就是只考虑利润—— 扩充和替换系统看上去似乎并不会为我们带来直接的利润。但是仔细考虑这份“什么也不做”的选项却发现，它其实强化了业务的抗风险能力。我们之所以要做这件事，原因在于如果不做将会增加由于IT失效可能给业务带来的风险。
其中的奥秘同系统及其构件的使用寿命有关—— 也就是继续获得可靠支持的难度。一个综合性的信息技术系统是否足够强健是由它最弱的那个环节所决定的。偶尔，系统也会到达其“增长的极限”，已有的业务容量可能不再有能力在可接受的响应时间内处理完所有的业务—— 也就是说系统达到了其处理能力的极限。
对任何一个系统而言，如果我们从它的完整生命期视角出发，在理论上应该能找到一个最恰当的点，一旦处理能力达到或者超过了这个点，那么从维护的角度上说必须重写应用。只有到了那个时候，长期累积下来的“绷带”才可以去掉，换上新的肢体。看上去或者从直觉上，我们大概能够分辨出这个点。但是现实可能又是另一回事，既缺乏系统更新所需要的资金，也缺乏重写系统的愿望。因此，很多机构就会选择推迟行动，让系统带着问题继续运行。通常情况下，系统每年更新费用都会在总费用里按期支付，直到接到IT或者业务部门的终止指示为止。一旦通过了终止点，系统的更新将明显地会受到持续性的投资结构的制约。
如果我们能发现一个对系统组合进行风险管理的业务案例，将会为有助于业务部门更多地支持并认可IT更新活动。其实发现这样的案例并不难，可以从扫一眼停车场里面的车子开始。你将发现，停车场里大多数车辆的车龄都不会超过5年，其中的很大一部分又会在下一个5年内被替换掉。替换的理由并不是这些车不能再用了。
当然，汽车和信息技术系统之间还是存在着很大的不同。至少还有二手汽车市场存在，在那儿你可以把你的车卖掉。而信息技术系统就不同了，如果被替换下来的话，它只能“退休”。一个退役的信息技术系统大概除了被销毁之外，只能当作来自久远年代的艺术品放到博物馆里收藏了。
具体到一个业务系统上面，这种“保持现状”选项我们也必须把握，需要综合IT风险可能对业务造成的影响以及造成风险损失的可能性，对IT投资做积极而审慎地思考，进而做出决策。而业务风险状况得到的逐步改善应该被看成是从这些变更中所获得的利益。如果我们选择了“什么也不做”，最后导致风险逐步加大，那么通过对这种状况的仔细评估，在同业务部门进行充分的沟通以后，“做些什么”这个选项的重要性也会得到大家的认同，接下来就会把注意力逐渐转移到什么时间、能做好哪些事情上来。
要回答“何时”的问题，我们就必须估算变更实施的起始时间。正如本章前面所讨论的，项目的时间实际是一个具有很大可变性的目标。
在理想的情况下，在一个替换/扩充型项目交付期间，应当允许系统有一个稳定期，将现有系统“锁定”或者“冻结”。
在这方面，有两种得到广泛采用的策略：
● “变更最小化”或者“出什么问题、解决什么问题”式的升级，非必要的特性不做变更(例如，对新的数据库版本的支持)。
● 改换系统—— 如果在内容上，变更的项目能使业务和IT双方得益的话，那么也可以剔出一些IT风险，交付一个面貌一新的系统。
简单的“出什么问题、解决什么问题”式升级是最容易实现的—— 仅仅需要一个理由：为什么要替换它们——
就已经足够了。但是，我们还必须从业务角度出发，比照着考虑。如果我们已经选择了“什么也不做”，那么除非存在“现实和紧迫”的危险，那么这个选项就不能被跳过去或者中场放弃。
对于那些介于上述两种情形之间的状况，也许把升级和改换系统结合起来是一个不错的选择，但这可能会给某些利益相关者带来认知上的混乱。这个时候，沟通是最重要的，因为它可以避免产生这样的一种误解，那就是IT负载了一项带有IT日程的商业项目。大家都会发现，为了达到项目“分享资金”的目的，把业务日程同IT日程结合起来是很方便的做法。很多同2000年问题相关的企业资源规划(ERP)都无法达到预期的目的，这个例子充分地说明把“必须做的”同打算获利的变更项目混合在一起并不容易，整个过程还是需要积极的管理。
有关IT风险组合的结构化风险评估框架也适用于升级和替换类型的IT项目。
● 需求的稳定性。
● 项目团队的技能和经验。
● 采用的技术类型和数量。
我们认为这些因素将会不时出现在项目生命周期的各个阶段，在整个项目生命周期内，要求注意克服这些因素，以降低可能对机构带来的潜在风险。
1. 需求的稳定性—— 灵活性的需要
很多领域的IT项目失败都同项目范围的变化有关。冻结项目范围也许并不恰当，可是这个选项之外，还有什么其他的办法供我们去选择吗？深入地思考这个问题，对我们来说是非常有意义的。项目已经满足了原定的规范要求，但却无法满足当前的业务需求，在方案交付的过程中，什么时候可能会发生这种情况呢？
把项目的风险因素都找出来，并且逐个把它们都说清楚—— 风险的起因与后果，这是很有用的—— 比如，由于项目范围的扩大可能会造成整个项目被迫推迟交付，费用也会增加。针对这项风险，就有必要采用一套方法来管理需求乃至整个项目的范围。对项目经理来说，这套方法就同“面包和黄油”一样，是项目管理的必需品。尽管来自于项目监督的刨根问底式的问题也足以把这个问题搞得一清二楚。
通常，采用“扩大范围、宁多勿少”的方法是避免后期项目范围变化的方法之一。但是，与之相反的观点也有点似是而非：积极参与的用户群将持续不断地为既定的项目规范提供改进意见。
但从IT方案供应商的角度看，未必就把项目范围的扩张看成一个风险。相反，他们也把它看成一个机会。项目“已定价”部分将按时交付，接下来的变更需求就可以确定下来，带来的利润也一定非常可观。从另外的角度看，增加投入使新版本的应用能交付更多有价值的功能，也是一个改进现有系统的机会，同样会带来巨大的商业价值。
总之：
● 范围的扩展未必就是坏事。
● 在整个项目生命期内，及时发现项目范围变更所造成的影响是非常重要的。尽管对单个项目来说，采用什么样的方法去管理项目范围还需要仔细斟酌，但几个可以参照的通用模式还是能找得到的。
● 扩大项目范围也为我们带来机会—— 解决方案将会为我们带来全新的、具有商业价值的、与众不同的成果—— 尽管还需要同费用一起加以考虑。
2. 技能和经验—— 依赖于团队
从单个的项目角度考虑，在较短的时间内获得一个具体的成果，其实是保护项目实施团队安全的最好的做法(Jiang和Klein，2000)。他们不得不小心翼翼，直到方案上线才敢“松口气”。
但从机构的角度来看，这未必是“正确的做法”。的确，不是每一个项目都有团队。今天也许A团队被解散了，人员也离开了，或者调去从事其他更重要的工作了，那么会发生什么样的事情呢？
一个项目团队适当吸收一些技能平平的人有时还是必要的—— 至少，这些技能平平的人的加入还能让这支团队的平均技能保持在一定水平上—— 对这种项目团队来说，一方面要有效地利用团队的知识和技能，另一方面还要让团队起到员工训练基地的作用。
同那些老手相比，新手或者没什么经验雇员的“风险”只会发生在他们进入项目团队之后。但我们应该看到，他们也为项目带来了新的视角，在项目的研究阶段会给项目带来很多积极的方案选择，这确实是一种难得的资源。他们从其他开发环境所获得的开发经验现在是发挥作用和优势的时候了。积累的经验在这儿成了新技术技能，对正在进行的项目而言，尤其显得重要。
总之：
● 一个团队不会同时做所有的项目。
● 项目部署为员工的在职培训提供了场所，也为培养“明日的团队”提供了一个难得的机会。
● 新的技能需要新的血液。
3. 技术的数量和类型—— 你要认识的魔鬼
和员工的技能、经验风险因素相似，从“风险检查清单”里我们还能发现另外的一种强烈的暗示，那就是使一个项目里，使用的技术种类越少越好。无论如何，对我们来说，新的技术都是未知的，它们未必能像我们期望的那样发挥作用。
当然，经历较长的时间以后，新的技术一定会在系统环境中出现。因为，我们又要同时避免操作风险的增大—— 新平台不支持旧技术。
这个问题带给我们的最大挑战在于，如何在创新压力下寻求新老技术结合上的某种平衡。将新老技术相结合可以让我们找到一条交付方案的捷径，让我们可以直接使用新技术，同时也保留着随时“退回到老技术”的选择。
在我们考虑在一套方案里使用多少技术时，有一点非常重要，那就是要考虑技术的兼容性和协同工作的能力。也许我们并不能指望多家供应商的方案“穿插”在一起还能很好地工作。相反，来自单一技术供应商的多个方案也许还可以通过产品之间的接口，结合在一起协调工作。
但作为一条原则，应该谨记：早期版本的技术产品应该尽量避免使用。原因是这些技术所依赖的标准可能刚刚出现。这就是说，在一个开放系统环境下，使用10种左右的技术方案构件是比较适当的，每种构件都作为综合解决方案的一部分发挥其最佳功能。例如，三层WEB方案“栈”可以包括下列组件：
● 前端—— 分布式的客户端，表示层模块或者薄客户层“浏览器”(1)；中心服务器，表示层模块或“Web服务器”(2)；
● 应用逻辑—— 遵从J2EE规范的客户化应用逻辑(3)，运行在商用的“应用服务器”(4)上的第三方和开放源码软件构成的解决方案(5)；
● 数据管理—— 关系型数据库管理系统(6)；
● 安全基础设施—— 防火墙和入侵检测与监控(7)；
● 管理报告工具(8)；
● 系统管理工具(9)；
● 备份和恢复机制(10)。
所有的上述构件都分别驻留在不同的机器里，运行在不同的操作系统上。在这些构件的背后可能还有一些适配器和中间件层来保证彼此之间的耦合和连接。
方案做得这么复杂也不一定就是件坏事！拟采用的方案同以前的方案(单纯的单一构件)相比，在可扩展性、集成性和将来的可移植性方面都有了重大的改进。
同新技术有关的一个重大警告信号是：采用和应用那些很多信息技术专业人士所热衷的新技术所获得的商业利益并不大。对每一波的新技术而言，只有有限的机会之窗能使极少数的信息技术专业人员变成在职业和收入方面领先大众的所谓“专家”。在采用新技术的时候，可能会使“第一个吃螃蟹”的机构陷入“试验和犯错”恶性循环，但却会为个人成为所谓的“专家”指明了道路。就好像一个风险投资者打中了市场却被别人拿走了奖金一样。
4.3.4 可以选择的交付模式及其风险特征
当今最通用的两种交付模式中，一种称为“经典”的瀑布方法(即结构化系统分析和设计方法及其变种)，第二种则是更现代的迭代方案交付方法(即统一流程及其变种)。每一种都有其独特的风险特征、管理要点和值得关注的地方。
“经典”式瀑布方法类似一条生产线，其中的每项任务都有定义好的“上游”和“下游”关系。下游任务必须等待上游任务完成以后才可以开始。上游产生的任何缺陷都会被带往下游。重新生产的过程冗长而且开销巨大。从好的方面说，这可以比较容易地定位所有问题(在最小的时间里返回到那个环节)，尽管断开环节之间的次序依赖关系也是很困难的，因为这会受到来自产品“按时上市”要求的挑战。延迟和厌恶的冲击—— 包括找出罪魁祸首—— 将会发生在瀑布模式里，尽管责任人是明确的，但解决问题的办法就未必。
瀑布模式的管理要点和值得注意的地方主要在于每一个完成步骤的(退出判据)检查点。
在更现代的迭代方案交付方法里面，内置了规范的“螺旋”机制。每一个“子”方案都需要进行分析、设计、构造和测试—— 然后才是集成。尽管类似的瀑布模式常常也会引入到“末代循环”次序关系里，但是在开始建构整个方案之前，对分析和方案设计的完备性并没有特别的要求。理论上，方案中最困难的部分应该是迭代的开始阶段——如果必要，可以把未解问题保持在最长的迭代循环中——而最简单的方案构件则会在最后一轮的迭代过程中加入。在这这种模式下，尽管每经过一次迭代，交付的确定性都会获得提升，但是在项目早期阶段期望获得可靠的交付估计仍然是非常困难的。延迟和厌恶的冲击——包括找出罪魁祸首—— 通常在这种模式下不会出现。而这种模式的最大风险在于经历了持续的迭代以后，总是显示只完成了总工作量的90％。
尽管从逻辑上讲，还可能会出现一种情况，即在每一次重要迭代之后都要像整个方案结束时所做的一样，需要进行认受性测试。但是值得欣慰的是，在这种模式下，管理上并没有那么多突出的问题，需要关注的地方也没那么明显。
4.3.5 开发之外—— 项目的保障和升级
大多数讨论到IT项目风险的文献都把焦点集中在新软件的开发上。但在很多大型机构里面，更普遍的IT项目还是对现有系统的修改，当然也可能伴随着少量的新软件开发。那么，这些软件升级类项目的风险形式会是什么样的呢？
1. 升级
借助现有的系统可以把IT项目的相关风险降到最低—— 技术是了解和熟悉的，还有现成的专家负责。而且还很容易估算出时间和费用成本。为了保证质量，还可以继续采用很好的测试方法和测试计划。
然而，这类项目也面临着很现实的风险：
● 因为升级，可能会引入新的缺陷，从而导致运行在现有系统上的业务中断。
● 可能为现有系统带来“过保障”风险，最后使系统更不灵活，更难以作出变更，就像绑在身体上的层层绷带一样。
想用昨天的架构来建构今日的方案，出现问题在所难免。在一群彼此关联的老系统的基础上，通过变更接口和相关软件来实施新的方案，时间和成本上的耗费将会使变更所带来的功能性成效大打折扣。一套结构上更清晰，耦合上更松散，也更符合现代潮流的技术架构将为我们带来更具可预测性、更有成效的、也更直接的功能提升。
2. 扩充与替换
那些交付商业价值很低，甚至根本不会带来利益回报，却因为某些原因不得不上的系统，在所有的IT项目中大概算得上是吸引力最小的了。那么，我们为什么还要实施根本没有商业价值的IT项目呢？
单纯从商业价值角度看—— 也就是只考虑利润—— 扩充和替换系统看上去似乎并不会为我们带来直接的利润。但是仔细考虑这份“什么也不做”的选项却发现，它其实强化了业务的抗风险能力。我们之所以要做这件事，原因在于如果不做将会增加由于IT失效可能给业务带来的风险。
其中的奥秘同系统及其构件的使用寿命有关—— 也就是继续获得可靠支持的难度。一个综合性的信息技术系统是否足够强健是由它最弱的那个环节所决定的。偶尔，系统也会到达其“增长的极限”，已有的业务容量可能不再有能力在可接受的响应时间内处理完所有的业务—— 也就是说系统达到了其处理能力的极限。
对任何一个系统而言，如果我们从它的完整生命期视角出发，在理论上应该能找到一个最恰当的点，一旦处理能力达到或者超过了这个点，那么从维护的角度上说必须重写应用。只有到了那个时候，长期累积下来的“绷带”才可以去掉，换上新的肢体。看上去或者从直觉上，我们大概能够分辨出这个点。但是现实可能又是另一回事，既缺乏系统更新所需要的资金，也缺乏重写系统的愿望。因此，很多机构就会选择推迟行动，让系统带着问题继续运行。通常情况下，系统每年更新费用都会在总费用里按期支付，直到接到IT或者业务部门的终止指示为止。一旦通过了终止点，系统的更新将明显地会受到持续性的投资结构的制约。
如果我们能发现一个对系统组合进行风险管理的业务案例，将会为有助于业务部门更多地支持并认可IT更新活动。其实发现这样的案例并不难，可以从扫一眼停车场里面的车子开始。你将发现，停车场里大多数车辆的车龄都不会超过5年，其中的很大一部分又会在下一个5年内被替换掉。替换的理由并不是这些车不能再用了。
当然，汽车和信息技术系统之间还是存在着很大的不同。至少还有二手汽车市场存在，在那儿你可以把你的车卖掉。而信息技术系统就不同了，如果被替换下来的话，它只能“退休”。一个退役的信息技术系统大概除了被销毁之外，只能当作来自久远年代的艺术品放到博物馆里收藏了。
具体到一个业务系统上面，这种“保持现状”选项我们也必须把握，需要综合IT风险可能对业务造成的影响以及造成风险损失的可能性，对IT投资做积极而审慎地思考，进而做出决策。而业务风险状况得到的逐步改善应该被看成是从这些变更中所获得的利益。如果我们选择了“什么也不做”，最后导致风险逐步加大，那么通过对这种状况的仔细评估，在同业务部门进行充分的沟通以后，“做些什么”这个选项的重要性也会得到大家的认同，接下来就会把注意力逐渐转移到什么时间、能做好哪些事情上来。
要回答“何时”的问题，我们就必须估算变更实施的起始时间。正如本章前面所讨论的，项目的时间实际是一个具有很大可变性的目标。
在理想的情况下，在一个替换/扩充型项目交付期间，应当允许系统有一个稳定期，将现有系统“锁定”或者“冻结”。
在这方面，有两种得到广泛采用的策略：
● “变更最小化”或者“出什么问题、解决什么问题”式的升级，非必要的特性不做变更(例如，对新的数据库版本的支持)。
● 改换系统—— 如果在内容上，变更的项目能使业务和IT双方得益的话，那么也可以剔出一些IT风险，交付一个面貌一新的系统。
简单的“出什么问题、解决什么问题”式升级是最容易实现的—— 仅仅需要一个理由：为什么要替换它们——
就已经足够了。但是，我们还必须从业务角度出发，比照着考虑。如果我们已经选择了“什么也不做”，那么除非存在“现实和紧迫”的危险，那么这个选项就不能被跳过去或者中场放弃。
对于那些介于上述两种情形之间的状况，也许把升级和改换系统结合起来是一个不错的选择，但这可能会给某些利益相关者带来认知上的混乱。这个时候，沟通是最重要的，因为它可以避免产生这样的一种误解，那就是IT负载了一项带有IT日程的商业项目。大家都会发现，为了达到项目“分享资金”的目的，把业务日程同IT日程结合起来是很方便的做法。很多同2000年问题相关的企业资源规划(ERP)都无法达到预期的目的，这个例子充分地说明把“必须做的”同打算获利的变更项目混合在一起并不容易，整个过程还是需要积极的管理。
有关IT风险组合的结构化风险评估框架也适用于升级和替换类型的IT项目。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved